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.

Reply via email to