On 2013-04-29 23:37:43 -0400, Peter Eisentraut wrote:
On Sat, 2013-04-06 at 12:59 -0400, Tom Lane wrote:
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
On Fri, Apr 5, 2013 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, 2013-04-06 at 12:59 -0400, Tom Lane wrote:
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
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
On 09/04/13 08:41, Peter Eisentraut wrote:
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
Peter Eisentraut pete...@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
On Fri, Apr 5, 2013 at 9:45 PM, Peter Eisentraut pete...@gmx.net wrote:
So I think this is not a compiler bug or an arms race. We just need to
fix the code. So I'm in favor of backporting.
I can certainly see this argument. I understand Tom's point about an
arms race, but back-porting this
After quite a bit of hair-pulling trying to install Fedora 19 Alpha,
I've been able to reproduce the initdb-time failure that's currently
being seen on buildfarm member anchovy, and was also complained of
recently by an end user:
On Fri, Apr 5, 2013 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It also strikes me that we ought to take this as a warning sign
that we need to work on getting rid of coding like the above in favor
of genuine flexible arrays, before the gcc boys think of some other
overly-cute optimization
On 06/04/13 11:14, Tom Lane wrote:
After quite a bit of hair-pulling trying to install Fedora 19 Alpha,
I've been able to reproduce the initdb-time failure that's currently
being seen on buildfarm member anchovy, and was also complained of
recently by an end user:
Peter Geoghegan p...@heroku.com writes:
On Fri, Apr 5, 2013 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It also strikes me that we ought to take this as a warning sign
that we need to work on getting rid of coding like the above in favor
of genuine flexible arrays, before the gcc boys
On 2013-04-05 23:28:03 +0100, Peter Geoghegan wrote:
On Fri, Apr 5, 2013 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It also strikes me that we ought to take this as a warning sign
that we need to work on getting rid of coding like the above in favor
of genuine flexible arrays, before
On Fri, Apr 5, 2013 at 11:39 PM, Andres Freund and...@2ndquadrant.com wrote:
The respective macro magic is already in place, its just not used in all
places. The problem is more that we can't easily use it in all places
because e.g. in the one case mentioned here the array isn't in the last
Andres Freund and...@2ndquadrant.com writes:
The respective macro magic is already in place, its just not used in all
places. The problem is more that we can't easily use it in all places
because e.g. in the one case mentioned here the array isn't in the last
place *in the back branches*.
I
Peter Geoghegan p...@heroku.com writes:
Are you proposing that we use the FLEXIBLE_ARRAY_MEMBER macro in every
single place where we currently use the one element array pattern?
Yup, exactly.
I count one place where we currently use FLEXIBLE_ARRAY_MEMBER. It'd be
pretty ugly to have that
On Fri, Apr 5, 2013 at 11:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm, I see 4 places in HEAD. But in any case, is
My mistake. I had REL9_2_STABLE checked out.
int16values[1];/* VARIABLE LENGTH ARRAY */
} int2vector; /* VARIABLE LENGTH STRUCT */
On Fri, 2013-04-05 at 18:14 -0400, 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
On Fri, 2013-04-05 at 23:44 +0100, Peter Geoghegan wrote:
On Fri, Apr 5, 2013 at 11:39 PM, Andres Freund and...@2ndquadrant.com wrote:
The respective macro magic is already in place, its just not used in all
places. The problem is more that we can't easily use it in all places
because e.g.
18 matches
Mail list logo
