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: unassig...@gcc.gnu.org
ReportedBy: rsand...@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.
