C constant expressions proposals

[Geoff Keating]

On Aug 17, 2004, at 2:38 PM, Joseph S. Myers wrote:

> On Tue, 17 Aug 2004, Geoffrey Keating wrote:
>
>> The point of 20010327-1.c is that it's the only way to get certain
>> functionality out of the linker.  It's necessary for strange cases
>> involving, for instance, an interface between 32-bit and 64-bit code.
>> It's perfectly OK if this is only accepted in an initializer, but it
>> does need to be accepted.
>
> So what (in terms of target macros if necessary) is the specification 
> of
> exactly what cases are meant to be accepted?  I gave the examples
>
> static unsigned long x = (unsigned long) ((uintptr_t)&_text + 123) + 
> 456;
> static long y = (long) ((intptr_t)((uintptr_t)&_text + 123)) + 456;
>
> which are both of the given form (extend an address constant to a wider
> type, then add a constant), but are they valid?  What about converting 
> to
> a narrower type?

There doesn't appear to be any target macro that currently exists to 
tell you what variants are accepted by a particular target.

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)').

Now, of course not all of those work on all platforms.  Some of them 
have a restriction on the possible sizes of 'A'.  Some of them work 
only when parts of the computation can be done by the assembler, so it 
depends on exactly what addresses you take, for instance '&x - &y' 
might only work if the assembler can compute it or 'y' is the same 
section as the object being initialised.  Some of them will fail in 
output_addr_const when it doesn't know how to multiply.  However, I 
believe there is at least one assembler/linker combination that can do 
the fully general case (in fact, I believe there's one combination that 
can handle even nonlinear expressions, although I don't know why you'd 
want to use that).

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040817/4ca1a641/attachment.p7s>