This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C constant expressions proposals


On Sat, 14 Aug 2004, Gabriel Dos Reis wrote:

> I would like to mention the following proposal
> 
>   Generalized Constant Expressions
>   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1521.pdf
> 
> that has been well received and encouraged at the Kona meeting of the
> C++ standards meeting. I believe, in all modesty, that it is a
> extension worth having in GNU C and GNU C++, pending final vote from
> the C++ standards committee.

This looks more in the spirit of C++ than C (since, for example, C does 
not include const variables in constant expressions).  There is however no 
intrinsic problem with having such an extension to C when an appropriate 
attribute is used on the function definition (without, it would violate 
the constraint that constant expressions shall not contain function calls, 
and my proposals are designed to be safely within what ISO C permits 
without needing any reference to -pedantic - and implementation would 
incidentally get rid of one place where -pedantic might affect code 
generation).

I take it you require the body of such an inline function to be visible 
before the use of a call in a constant expression?  Without that, at least 
in C you'd get nasty problems with making sense of the program at all.

Do you require the arguments to such a function to be integral constant 
expressions, and the function to return an integral type, for it to be 
used in integral constant expressions?  May parameters have floating point 
type?  What about floating point constants passed as arguments for 
parameters of integer type (and so implicitly converted to integer type, 
where an explicit conversion would be OK)?

I have found and corrected two bugs in the rules for GNU C constant 
expressions: they allowed such expressions as 1 - (intptr_t)&x, and didn't 
describe how typeof was handled.  I have also adjusted them to allow unary 
plus on address constants of integer type, so that +(intptr_t)&x is just 
as valid as (intptr_t)&x.

http://www.srcf.ucam.org/~jsm28/gcc/#const

The models for C90 and C99 constant expressions remain unchanged.

Further comments on any aspects welcome.  Given the past heated debates on 
the validity of gcc.c-torture/compile/20010327-1.c I'm a bit surprised at 
the lack of any comments on its reinvalidation (or more generally on the 
choice of extensions for GNU C; given past strongly stated opinions on 
such extensions both to constant expressions and elsewhere I'd have 
expected some people to object that there were too many useless extensions 
included and others (or indeed the same people) that important extensions 
used by real code were omitted).

I have started implementing the conversion of declarator handling in the C 
front end from trees to special-purpose datastructures as used for C++, as 
one of the preliminaries to constant expressions implementation which is 
also of value in its own right.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]