On 2013-01-12 18:15:17 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2013-01-12 13:16:56 -0500, Tom Lane wrote: > >> However, using a do-block with a local variable is definitely something > >> worth considering. I'm getting less enamored of the __builtin_constant_p > >> idea after finding out that the gcc boys seem to have curious ideas > >> about what its semantics ought to be: > >> https://bugzilla.redhat.com/show_bug.cgi?id=894515 > > > I wonder whether __builtin_choose_expr is any better? > > Right offhand I don't see how that helps us. AFAICS, > __builtin_choose_expr is the same as x?y:z except that y and z are not > required to have the same datatype, which is okay because they require > the value of x to be determinable at compile time. So we couldn't just > write __builtin_choose_expr((elevel) >= ERROR, ...). That would fail > if elevel wasn't compile-time-constant. We could conceivably do > > __builtin_choose_expr(__builtin_constant_p(elevel) && (elevel) >= ERROR, ...) > > with the idea of making real sure that that expression reduces to a > compile time constant ... but stacking two nonstandard constructs on > each other seems to me to probably increase our exposure to gcc's > definitional randomness rather than reduce it. I mean, if > __builtin_constant_p can't already be trusted to act like a constant, > why should we trust that __builtin_choose_expr doesn't also have a > curious definition of constant-ness?
I was thinking of something like the above, yes. It seems to me to generate code the compiler would need to really make sure the condition in __builtin_choose_expr() is really constant, so I hoped the checks inside are somewhat strict... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
