This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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)