------- Comment #4 from joseph at codesourcery dot com 2008-12-06 22:53 ------- Subject: Re: __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
On Sat, 6 Dec 2008, sabre at nondot dot org wrote: > Ok, so this is a special case when __builtin_constant_p is immediately the > operand of "?:"? Do you allow things like __builtin_constant_p(...)+0 as the > operand? Yes, this is a (documented) special case required to be compatible with existing GNU C code. __builtin_constant_p(...)+0 is not allowed as the condition; the bcp_call property propagates though parentheses and through being an operand of __builtin_choose_expr, but not otherwise. For example, ((__builtin_choose_expr(1, (__builtin_constant_p(...)), 1))) has the bcp_call property. I think the description in my formal model is right for how this property propagates, except it leaves it unclear what the property is for the result of a conditional expression where both the condition and the selected half of the expression have the bcp_call property. In that case, I don't think the conditional expression should have the property, and it doesn't in the implementation on c-4_5-branch. The formal model seems unclear here, but I think it should be interpreted as the bcp_call property being lost through the implicit conversion of the ?: operands to a common type. What I didn't realise when writing the formal model is that the conditional expression, with a bcp_call condition, must be treated like the *folded* version of the selected half of the expression, since __builtin_constant_p tests constancy of the folded version. If __builtin_constant_p accepts (0 && foo()) as constant then this needs to be accepted in the selected half of the initializer. And for optimal handling of the use case for this use of __builtin_constant_p (in particular, detecting constant insn conditions when building GCC), such expressions as (0 && foo()) should be accepted as constant by __builtin_constant_p (0 may have been a macro expansion of TARGET_64BIT or similar). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
