[Bug target/17224] relocation truncated to fit: GPREL22

jsm at polyomino dot org dot uk gcc-bugzilla@gcc.gnu.org
Sun Aug 29 09:32:00 GMT 2004


------- Additional Comments From jsm at polyomino dot org dot uk  2004-08-29 09:32 -------
Subject: Re:  relocation truncated to fit: GPREL22

On Sun, 29 Aug 2004, pinskia at gcc dot gnu dot org wrote:

> Ok, I think I have an handle on this now, we are not rejecting &n - 
> 89477598 as a constant.

It is a constant - "an address constant for an object type plus or minus 
an integer constant expression" in the terms of ISO C.  This may only in 
the standard be intended to cover the case of one past the end of an 
array, but if the target can't handle the given example how can it handle

void *foo () { static int n[123456789]; static int *m = n + 123456788; 
return &m; }
main ()      { foo (); }

which is clearly valid (subject to implementation limits, which shouldn't 
cause a problem for this program on 64-bit targets)?

If we have problems with targets not being able to handle certain simple 
forms of constants that fall within my model (as opposed to Geoff 
Keating's wish to accept bizarre examples such as '(uintptr_t)&x * 4 + 
3141 + (&z - &t)' that some assemblers can handle) we may need to have a 
target hook that does

  sorry ("no relocation available that supports this constant");

for the case of static initializers (or, better, warns then creates a 
constructor to initialize at runtime).

The present program however doesn't involve a static initializer, so 
should cause no problems or warnings.  If the assembler doesn't accept the 
address constant as constant, and it is being used as here in a context 
where a constant expression isn't required, it should simply be evaluated 
at runtime.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224



More information about the Gcc-bugs mailing list