Re: Back branches vs. gcc 4.8.0

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

;-)