[patch] MIPS gas problems with gcc's explicit relocs
Richard Sandiford
rsandifo@redhat.com
Sat May 29 06:39:00 GMT 2004
More information about the Binutils mailing list
Sat May 29 06:39:00 GMT 2004
- Previous message (by thread): [patch] MIPS gas problems with gcc's explicit relocs
- Next message (by thread): [patch] MIPS gas problems with gcc's explicit relocs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Maciej, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes: > The recent addition of explicit relocation generation to gcc triggered > failures for inline assembly under certain conditions. Thanks for sticking up for the new gcc behaviour ;). I just wanted to point out that using %lo(...) in "m" constraints isn't in itself a new thing. And that includes "m" constraints in inline asms, since gcc doesn't treat them any differently from "m" constraints in its own internal patterns. For example, if you select non-abicalls o32 or o64 code, I think it's been possible for "m" to use %lo(...) for some time. (Unless of course you disabled it via -mno-split-addresses.) If allowing %lo(...) in dla isn't acceptable (I've no opinion either way really), then we'll just have to call: > asm("dla\t%0,%1" : "=r" (result) : "m" (foo)); ill-formed. You should only use "m" if the instruction can handle every valid memory reference. Richard
- Previous message (by thread): [patch] MIPS gas problems with gcc's explicit relocs
- Next message (by thread): [patch] MIPS gas problems with gcc's explicit relocs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list