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 ;-) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
