Jan de Visser <jan@de-visser.net> writes:
> On 2015-11-27 9:44 AM, Adrian Klaver wrote:
>> To me nonsensical would be trying to compile newer code using an old
>> compiler. What the OP did seemed to be in the realm of possibility as
>> I would think backwards compatibility kicks in.
> Well, maybe. But there's no way to *guarantee* it will work. And
> apparently it doesn't.
AFAICT, backwards compatibility is not something the gcc boys care about.
I suspect the particular complaint here is related to
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL9_1_STABLE Release: REL9_1_10 [649839dd9] 2013-08-21 18:31:48 -0400
Branch: REL9_0_STABLE Release: REL9_0_14 [e9e387a5b] 2013-08-21 18:31:51 -0400
Branch: REL8_4_STABLE Release: REL8_4_18 [8396d230f] 2013-08-21 18:31:54 -0400
Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches.
With this optimization flag enabled, recent versions of gcc can generate
incorrect code that assumes variable-length arrays (such as oidvector)
are actually fixed-length because they're embedded in some larger struct.
The known instance of this problem was fixed in 9.2 and up by commit
8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides
actually-variable-length catalog fields from the compiler altogether.
And we plan to gradually convert variable-length fields to official
"flexible array member" notation over time, which should prevent this type
of bug from reappearing as gcc gets smarter. We're not going to try to
back-port those changes into older branches, though, so apply this
band-aid instead.
Andres Freund
though there are certainly other places that we've had to change because
newer versions of gcc broke them.
regards, tom lane
