C++ PATCH to cp/decl.c: Timing name lookup

Joseph S. Myers jsm28@cam.ac.uk
Fri Feb 14 01:09:00 GMT 2003


On Thu, 13 Feb 2003, Zack Weinberg wrote:

> I am a little leery of this __constant_expression__ notion; I would
> prefer to see an explicit list maintained, in the documentation, of
> acceptable integer constant expressions over and above those in the
> standard(s).  The existing __extension__ should then suffice to avoid
> an error.

I don't like __extension__ meaning "make this constant" as well as "allow 
extensions in here".

There are places where something is required to be an integer constant
expression - bit-field widths, enum values, static array sizes.  There are
cases where we ask "is this expression an integer constant expression?"  
(and the code might be valid with different meaning in either case) -
determining whether something is a null pointer constant.  DR#261
attempted to disentangle the different cases, but the suggested response
in the Santa Cruz minutes is "The committee believes that the standard is
clear enough." - without actually saying what it means.

I suspect making __extension__ make things constant might cause problems
where __extension__ is used with its existing meaning in a macro that uses
extensions, and this wrongly makes some calls of the macro count as
constant.  That's why I prefer a separate extension to make constant
something using standard syntax that isn't constant within the standard.  
(Cases such as differences of labels that necessarily involve nonstandard
syntax aren't a problem here.)

I don't object to __builtin_offsetof (as long as it's implemented for C++
at the same time as C).  If there aren't other cases where something needs
to be forced to be constant perhaps __constant_expression__ can be
avoided, but I wonder what strange things people are using in initializers
at present (and have good reason to be so using).  There is the problem of
how to test that something gets folded if it isn't a constant expression -
it's a test for such a folding regression (using an initializer) that led
to the previous discussion of "symbolic difference constant expressions".

> One special case I care personally about: 
> (__builtin_constant_p (EXPR) ? (EXPR) : INTEGER_LITERAL) should be an
> acceptable integer constant expression no matter what EXPR is (as long
> as it is indeed an expression).  This is currently true, and 
> insn-conditions.c relies on it.

Does the C++ front end (which now implements the C++ rules - much simpler 
than the C99 ones - for constant expressions) implement this?

It means special-casing a condition of __builtin_constant_p in ?: (and I 
suppose && and ||) to be handled differently from a plain 0 or 1 constant.  
(So __builtin_constant_p mustn't have been folded by then.)

And I hope you mean that when __builtin_constant_p is used like this the 
unevaluated half is simply ignored for determining constantness - not that 
(__builtin_constant_p ((int)+0.0) ? ((int)+0.0) : 0) is an integer 
constant expression when (int)+0.0 is only an arithmetic constant 
expression.

-- 
Joseph S. Myers
jsm28@cam.ac.uk



More information about the Gcc-patches mailing list