------- Additional Comments From rth at gcc dot gnu dot org  2004-10-12 17:39 -------
Ah, I see some amount of confusion here.

Yes, in the referenced message I do argue for "asm volatile" to be a scheduling
barrier.  You'll note that what I'm most concerned about there is that the asm
remain in the body of the function and not get scheduled into the epilogue.
Which does indeed sound like it might could cause problems.  Too bad I didn't
bother to write a test case demonstrating what I had in mind, but there ya go.

As for transformations that are not *scheduling*, the documentation is also quite
clear: 'GCC will perform some optimizations across a volatile asm instruction;
GCC does not “forget everything” when it encounters a volatile asm instruction'.

Which means that if you try to use volatile asms for fp control word
manipulation, you will be sorely disappointed, because *every* existing pass
of the compiler will thwart you.  If you thought this worked before gcc 4.0,
you were mistaken -- tweak the test case a bit and it'll fail on any arbitrary
gcc release.

I have no particular interest in changing this, because gcc doesn't understand
#pragma FENV_ACCESS, and nothing you do until that support is added is going to
help.  I'll state for the record that FENV_ACCESS will be a *huge* amount of work.

We can clarify the documentation, if you can be specific about what you thought
was confusing, but that's the most I'm willing to accept for this PR.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |documentation
            Summary|[4.0 Regression] asm        |asm 'volatile' is not
                   |'volatile' is not honored as|honored as documented
                   |documented                  |


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