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 Tue, 17 Aug 2004, Geoff Keating wrote:

> I know there are targets can handle expressions of the form
> 
> <inttype A> x = (<inttype A>)(<address-linear-expression>)
> 
> for any integer type 'inttype A', and any <address-linear-expression> which is
> a linear combination of addresses where the computation is of the same size as
> an address (yes, including things like '(uintptr_t)&x * 4 + 3141 + (&z - &t)',
> or the equivalent but more fun '(uintptr_t)((int *)3141 + (uintptr_t)&x) + (&z
> - &t)').

The fact is, GCC does not accept such expressions; they don't pass 
initializer_constant_valid_p; although of course a model could be written 
to describe such expressions.  In case of doubt about what was a constant 
expression in this area, I tested what in fact works with GCC and used 
that to guide the model.  An equivalent of 20010327-1.c using long long, 
or unsigned long long, doesn't work on x86 either: the initializer is 
rejected, by the compiler, as non-constant.  Does the testcase in fact 
actually work on the platforms with long wider than pointers?

Now, it would be possible to give a mandatory pedwarn ("initializer 
element is not a constant expression") rather than an automatic hard error 
for constructs in static initializers the middle-end thinks are constant 
but which don't meet the model of constant expressions (while abort()ing 
if something meets the model but the middle-end doesn't think it 
constant), and this is what currently happens in some cases, but where a 
construct may be used in legitimate code it would be much cleaner to model 
the valid constructs explicitly.

> My suggestion is to just permit any expression of the form above and document
> that the assembler gets to say whether it's valid or not.  Alternatively, make
> a target hook that can look at trees.

It's the job of the front end to reject invalid code and pass down valid 
code to the next level.  It's the jobs of the compiler to pass only valid 
code to the assembler unless there is something invalid an asm statement 
or similar.  While target hooks can be used for such things in the front 
end, that so far they haven't been needed is a strong indication that what 
GCC accepts really doesn't have or need such a strong target dependency as 
what the assembler accepts.

For the most bizarre target-dependent expressions you give, I think it 
make sense to expect such initializations to be done in assembler code 
rather than C.  (Perhaps a suitable form of asm expressions might make 
this more convenient, if there really is a use for such expressions.)

-- 
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]