Re: [PATCH] PR c/456: C90 warning for non-constant initializers

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Wed, 23 Jun 2004, Roger Sayle wrote:

> where in C90 the initializer isn't/shouldn't be considered constant.
> The problem is simply that "fold" is doing it's thing, and reducing
> the above expression at compile-time to zero, which prevents the C
> front-end from issuing a warning.  Compile-time folding of COND_EXPR
> in initializer is apparently allowed in C99, but alas not in C90.

The "allowed" in C99 is a bit misleading.  Certain usages don't violate
the constraints on constant expressions.  Thus they might occur in the
"other forms" of constant expressions.  Experts differ on whether they may
occur in integer constant expressions (as an "other form") or whether
"other forms" are only permitted in initializers rather than to be one of
the named forms.  (All the things not permitted in constant expressions by
the constraints, except in sizeof in C90 or in unevaluated subexpressions
in C99, except comma expressions, would fail the restrictions on operands
of integer constant expressions in the semantics.)  In any case, that
would be an extension.  We don't document any extensions to constant
expressions except addresses of labels, __builtin_types_compatible_p,
__builtin_constant_p and the __builtin_nan functions.  So we are free to
minimise the permitted extensions, and so should do so.  The two main ones
that have been requested are differences between addresses of labels (in
initializers only), and the example

>   static int x = (__builtin_constant_p (0) ? 0 : foo ());

you give with __builtin_constant_p as a condition (making the result have
all the constant properties of the selected half).  More general folding
in C99 mode isn't one of them, though the special case with unevaluated
comma expressions needs accepting.  (None of this can depend on -pedantic,
because changing the constant expression decision can both add and remove
diagnostics.  None of it should depend on flag_iso either.)

This patch only addresses the tip of the iceberg, as indeed do the
testcases currently in the tree (they are all correct, in that the desired
state for GCC would have all the XFAILs currently passing, but I now have
a better understanding of how constant expressions are much more
complicated than the testcases would suggest).  I'm not convinced building
kludge upon kludge to fix some instances only of an obscure long-standing
problem noticed by few users is particularly useful.  Even for the
regressions, if there's a simple local fix it might be worthwhile (say, if
tree-ssa has obsoleted the use of the C front end's local optimizations
replacing const variables with their initializers, so they could go away
and with them all checks on "optimize" in the C front end) but otherwise
XFAILing might make more sense.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)