Re: Back branches vs. gcc 4.8.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Back branches vs. gcc 4.8.0
Date: 2013-04-06 16:59:14
Message-ID: 6111.1365267554@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2013-04-06 18:16:51 isolation test fails on installcheck
Previous Message Andres Freund 2013-04-06 14:44:03 Re: corrupt pages detected by enabling checksums