http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56027
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> 2013-01-18 11:14:53
UTC ---
(In reply to comment #1)
> I think you want a pass-thru:
>
> #define opaque(x) __asm volatile ("# x" : "=g" (x) : "0" (x))
(opaque returns a value in my example, but that's a detail)
Replacing my asm with yours indeed works (as I said, adding volatile seems to
be enough).
The reasons we are using "mx" instead of "g" are:
* on 387 it has the bonus side effect of forcing the number to 64 bits,
* on some version of gcc (can't remember which) "g" somehow did not work as an
optimization barrier while "mx" did,
* there are few other places a double could be on x86,
* we have an alternate code for non-gcc or non-x86 where we write/read a
volatile variable.
I'll probably change it to "g" later though on platforms where it is safe,
thanks.
Is there a particular benefit in using "=g" and "0" instead of the shorter
"+g"?
I am mostly wondering what guarantees I have there won't be re-ordering. *mxcsr
are unspec_volatile and thus can commute with asm (register) but not asm
volatile or asm (memory in V1)? And function calls (fesetenv in V2) can't
commute with regular asm, volatile isn't required there?
(otherwise it's just the usual "-frounding-math doesn't work", the asm
shouldn't be necessary at all, but I'd like to be sure my workarounds work...)
