[Bug target/52125] New: Problems with LO16 asm operands on MIPS

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

             Bug #: 52125
           Summary: Problems with LO16 asm operands on MIPS
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rsandifo@gcc.gnu.org


On MIPS, the "m" asm constraint allows %lo16 addresses.
This can cause orphaned HI16 relocations on REL targets
if the memory operand isn't actually referenced in the
asm string, but is simply there to record that a particular
piece of memory is used or set.  This can be seen in
gcc/testsuite/gcc.dg/pr48774.c.

It's difficult to know what to do here.  On the one hand,
passing any mem to "m" in this way ought to work, so it is
a genuine bug.  On the other hand, I think "m" has allowed
LO16 addresses since -msplit-addresses was added all those
years ago, and I can't remember any complaints about it
causing problems in "real" code.  It would only cause
problems in cases where the CU has no other LO16 references
to the same address (or the same address plus a constant).

We could forbid LO16 "m" references on REL targets and provide
a new memory constraint that allows them, but that might
cause unnecessary pessimisation of working asm statements.
People who want the best performance would have to conditionalise
their code based on the GCC version, using "m" for old versions
and the proposed constraint for new versions.

Since this isn't a 4.7 regression, I'm not planning on
doing anything at this stage.