On 17/10/17 06:20, Xi Ruoyao wrote: > On 2017-10-17 00:27 +0200, David Brown wrote: > >> My testing suggests that gcc will re-order "asm volatile" statements >> that have an output, such as the "save the PRIMASK into status" >> statement, but it will /not/ re-order "asm volatile" statements that >> have no outputs. >> >> Is that correct? >> >> Is that the intended behaviour of "asm volatile" ? > > Yes. It's said in the documentation > <https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Extended-Asm.html>: > > Note that the compiler can move even volatile asm instructions relative > to other code, including across jump instructions. For example, on many > targets there is a system register that controls the rounding mode of > floating-point operations. Setting it with a volatile asm, as in the > following PowerPC example, does not work reliably. > > asm volatile("mtfsf 255, %0" : : "f" (fpenv)); > sum = x + y; > > The compiler may move the addition back before the volatile asm. To > make it work as expected, add an artificial dependency to the asm by > referencing a variable in the subsequent code, for example: > > asm volatile ("mtfsf 255,%1" : "=X" (sum) : "f" (fpenv)); > sum = x + y; > I have read the documentation page, several times. It does not answer my question. In particular, it makes it clear that volatile asm statements can move relative to /normal/ code - it does not make it clear how it relates to code that itself has movement restrictions (like volatile memory accesses, and other volatile asm statements). Secondly, neither the documentation nor your reply cover the other half of my observations and questions - namely that "asm volatile" statements with no outputs do not appear to be re-ordered. If this observation is in fact guaranteed behaviour by gcc, then it can be used to enforce ordering as required by the sort of code referenced in my first post. If gcc cannot guarantee this, then pretty much every OS and every embedded system programmed using gcc works by luck rather than design. Sequences like the one in my link are very common, deep down in many systems. >> If so, is that a good design choice or should it be changed? > > I don't know. I think it is just a choice, not so good and not so > bad. I fully appreciate why asm statements with outputs, and even volatile asm with outputs, can be moved around - optimisation of inline assembly is a strength of gcc. The key issue is with movement of volatile asm statements /without/ output. I want to know if these are allowed to move (with respect to each other, and with respect to volatile memory accesses) - if so, then that would be a /very/ bad design choice IMHO. > >> Could the documentation in the gcc web page be improved? > > The documentation is very clear. No, it is not. I hope with this post you (and others) will see my point, and see that the documentation does not cover the needs of developers. It is particularly surprising - shocking, even - for many developers to see that a "volatile asm" statement can be re-ordered with respect to volatile memory accesses. After all, a vital point of "volatile" in C is that it enforces an order - it is natural to assume the same applies to "volatile asm". Since this is clearly not true, the documentation should be shouting it in blinking red letters three inches high, not mentioning it briefly in the middle of the page. > >> Or is this a bug in gcc, and the statements should not have been re-ordered? >> >> >> David
