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.