http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56027
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-18
11:49:27 UTC ---
(In reply to comment #2)
> (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).
Ah, yes.
> 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"?
Not sure - I've just copied what is done elsewhere. +g should work as well.
> 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?
You always need volatile here, even if in practice it seems that it is
not required for a function call. volatile tells it that the asm is
a scheduling barrier for other volatile instructions.
> (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...)
Yeah...
So - it works for you then and we can close this bug?
