[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