[Bug target/11924] New: mips64-linux o32 accesses to certain file-local data incorrectly generated

[cgd at broadcom dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: mips64-linux o32 accesses to certain file-local data
                    incorrectly generated
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: cgd at broadcom dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mips64-unknown-linux-gnu
  GCC host triplet: mips64-unknown-linux-gnu
GCC target triplet: mips64-unknown-linux-gnu

with mips64-linux -mabi=32, accesses to certain file-local data are incorrectly
generated by the compiler, when using explicit relocs.

gcc and binutils trunk as of 2003-08-12 00:00 UTC, no local mods.

I have not tested this on mips-linux (which has only o32), but I suspect it 
would behave the same.  If so, that would make this a regression since the


The data in question appear to be:

* nested function cache trampolines, and
* coverage data storage areas.

(I've observed both of those, but of course there may be more.)


For whatever reason, the compiler is emitting only:

        lw      $3,%got($LTRAMP0)($28)

and not the also-necessary:

        addiu   $3,$3,%lo($LTRAMP0)

to get the address of $LTRAMP0 into a register.

This results in a failure of (among others), the nestfunc-1 tests.

To reproduce, I'd say build native mips64-linux, and test unix/-mabi=32.
As noted, I suspect that building mips-linux will produce the same result.

I suspect what's going on is that the mips back-end decides
the symbol is global, for some reason.  In that case, i believe the sequence
emitted would work properly.

a workaround is -mno-explicit-relocs.