https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602
--- Comment #16 from David Brown <david at westcontrol dot com> --- (In reply to Xi Ruoyao from comment #8) > (In reply to David Brown from comment #7) > > > There is no intention to make "asm volatile" a barrier, as you get with a > > memory clobber. The intention is to stop it moving past other volatile code > > (such as other asm volatiles, and volatile memory accesses). An "asm > > volatile" statement should still be moveable across other "normal" code. > > I see... But then your code in the maillist > Yes, of course if the compiler knows the contents of foo() (from LTO, or from a definition in the same file), then it can re-arrange any non-volatile statements there. That is a separate issue, and a known issue. For most purposes this can be handled just by using memory clobbers or appropriate use of volatile variables. For more advanced uses, fake dependencies in asm statements can also be used. This is all known territory. In order to get correct code, you need control of particular memory accesses within a critical region like this - execution and calculations don't matter, nor do local variables. That's why memory clobbers are nice - they may lead to some sub-optimal code, but they are an easy way to get it correct. For the best possible code, you may want control of calculations and execution as well - in particular, you want to minimise the processor time within the critical region. That is a lot harder, and there is currently no way to specify things fully (though with careful use of asm dependencies, you can get close). But that is another issue entirely, and it is a matter of code efficiency rather than code correctness. However, correctness here depends on the compiler honouring the ordering of volatile asm statements with respect to other volatile code, and this patch fixes that.
