There are occasions where gcc wants to read some subreg of an address
in the GOT (builtin_strlen is one example, depending on optimization).
However, this code in s390.c (s390_decompose_address()) seems to disallow
such constructs:
/* In the small-PIC case, the linker converts @GOT
and @GOTNTPOFF offsets to possible displacements. */
if (GET_CODE (disp) == UNSPEC
&& (XINT (disp, 1) == UNSPEC_GOT
|| XINT (disp, 1) == UNSPEC_GOTNTPOFF)
&& offset == 0
&& flag_pic == 1)
{
;
}
If I comment out the "&& offset == 0" line, gcc produces assembly like this:
l %r2,[EMAIL PROTECTED](%r12)
The assembler and linker don't seem to have a problem with that
construct. Are we deliberately avoiding it for some obscure reason,
or is this just a bug that's never been tripped over before?
If it's a bug, is there some test for a "reasonable" offset that we
can add, that makes sense? I'm thinking, if we know the maximum size
of a GOT entry, we can make sure the offset is within some range 0..N.
