On 09/04/13 08:41, Peter Eisentraut wrote:
> On 4/5/13 6:14 PM, Tom Lane wrote:
>> Since gcc 4.8 is going to be on a lot of people's machines pretty soon,
>> I think we need to do something to prevent it from breaking 8.4.x and
>> 9.0.x. It looks like our choices are (1) teach configure to enable
>> -fno-aggressive-loop-optimizations if the compiler recognizes it,
>> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9.
>>
>> I'm a bit leaning towards (1), mainly because I'm not excited about
>> fighting a compiler arms race in the back branches.
> At the moment, I wouldn't do anything. At least until we have converted
> master to use flexible array members completely, and we have learned the
> extent of the issue.
>
> The problem manifests itself easily through the regression tests, so
> there is no guessing about whether a particular combination of versions
> will work. Someone who uses a cutting edge compiler with a somewhat old
> PG release is doing something special anyway, so they should have the
> required skills to put in the workaround.
>
> I would rather avoid patching in specific compiler options for specific
> versions. These things come and go, but releases live a long time. How
> do we know -fno-aggressive-loop-optimizations is the only option we need
> in the long run? I'd rather see a direct crash or a known code fix.
>
> As an aside, we already have -fno-strict-aliasing and -fwrapv. Add more
> and it will begin to read like
>
> -fmy-code -fis-broken -fhelp-me
>
> ;-)
>
>
>
-fno-break-my-code