Comment 13 for bug 1722849

Revision history for this message
Johan Tufvesson (t-jot) wrote :

Interesting that there is a difference between one and several asm statements, but without a clear statement in the GCC manual I would not dare to rely on that fact for any functionality. Of course the "memory" clobbering is a vital part of this solution. Since I have seen way too many bugs related to not having the "memory" clobbering in general critical section macros they are a must have to me, and they do take care of the ordering in a guaranteed way on simple targets.

The only slightly related note I find in the manual is:
"asm statements that have no output operands, including asm goto statements, are implicitly volatile."

Any thoughts on the original behavior, which I think is faulty? If "volatile" code is not ordered in line with "volatile" memory accesses, I think it is either a buggy implementation or a buggy design, but I find nothing in the GCC manual to rely on. I would not have protested if the original foo() was known by the compiler to not have anything volatile, but in this case GCC does not know anything about foo(). foo() could for example contain another "asm volatile" statement, which I would have thought to be executed in the right order.

From the manual:
"Do not expect a sequence of asm statements to remain perfectly consecutive after compilation, even when you are using the volatile qualifier. If certain instructions need to remain consecutive in the output, put them in a single multi-instruction asm statement."

I thought (English not being my native language) that "perfectly consecutive" here meant that I should expect GCC to be able to put other code between my volatile asm statements, but that they would still remain consecutive with regards to each other. On the other hand, the second sentence only mentions "consecutive" and not "perfectly consecutive", so I might very well be wrong in that assumption. If I'm wrong here, I must say that I am disappointed on the GCC design, having so different behavior on volatile asm and volatile accesses.