Re: Back branches vs. gcc 4.8.0 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Back branches vs. gcc 4.8.0
Date
Msg-id 6111.1365267554@sss.pgh.pa.us
Whole thread Raw
In response to Re: Back branches vs. gcc 4.8.0  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Back branches vs. gcc 4.8.0
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> The reason that the whole code wasn't converted right away was (besides
> a lot of legwork with sizeof and offsetoff) that flexible array members
> aren't allowed in the middle of structs.  Which eventually led to the
> mentioned commit 8137f2c32322c624e0431fac1621e8e9315202f9.

> If someone wants to go through and change the rest of the code to use
> FLEXIBLE_ARRAY_MEMBER, I won't mind.  But I think it actually has
> nothing to do with the current bug or future-proofing anything.  All
> compilers tolerate the current coding.

The reason I'm thinking it's a good idea is that it would expose any
remaining places where we have nominally var-length arrays embedded in
larger structs.  Now that I've seen the failures with gcc 4.8.0, I'm
quite worried that there might be some more declarations like that
which we've not identified yet, but that by chance aren't causing
obvious failures today.  (This is also why I'm not that excited about
trying to fix things "properly" in the back branches compared to
selecting -fno-aggressive-loop-optimizations: I'm afraid there might
be more to it than just the one commit.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: corrupt pages detected by enabling checksums
Next
From: Jaime Casanova
Date:
Subject: isolation test fails on installcheck