<div class="moz-cite-prefix">On 09/04/13 08:41, Peter Eisentraut wrote:<br /></div><blockquote
cite="mid:51632B8B.4020508@gmx.net"type="cite"><pre wrap="">On 4/5/13 6:14 PM, Tom Lane wrote:
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">
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
;-)
</pre></blockquote><font size="-1">-fno<font size="-1">-</font>break-my-code<br /><br /></font>