Re: fix for strict-alias warnings - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: fix for strict-alias warnings
Date
Msg-id 002901c39247$7e720200$6401a8c0@DUNSLANE
Whole thread Raw
In response to Re: fix for strict-alias warnings  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: fix for strict-alias warnings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
>
> I have to agree now with Andrew's last mail that -fno-strict-aliasing is
> the only safe solution.  Since gcc isn't even pretending that it can
> warn in all cases where the optimization might break things, I'm not
> sure we could ever responsibly enable this optimization.  I do not feel
> this is our problem; it is the compiler hackers' fault if they need to
> make unsupportable, untestable assumptions about application code.
>
> Basically, ISO broke the language here, and I say it's a screwup up with
> which we need not put.
>

You and Linus Torvalds ;-) I recall seeing almost this exact discussion on
the kernel hackers list a few years ago.

Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers - which makes things somewhat easier for them. What is our target
set of compilers? What is our target version of C? (being unsure on these
issues I gave my initdb.c a tour through "gcc -ansi -pedantic" at one
stage).

Also note that uninhibited casting between types can still cause alignment
problems, quite apart from the strict aliasing issue (That was what confused
Bruce, I think - the email on the netbsd list referred to both strict
aliasing issues and misalignment issues). Still, that apparently hasn't been
a problem up to now so we are probably OK on this one.

cheers

andrew


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: fix for strict-alias warnings
Next
From: Tom Lane
Date:
Subject: Re: fix for strict-alias warnings