Can compilers break control dependencies used for LoadStore memory ordering or similar, in any real use-cases?

Question

I'm reading the mail list about LKMM: Add volatile_if(). The control dependency is somewhat subtle since it is easily forgotten by us developers. So I wonder is there any real case that is caused by control dependencies?

In fact, I found some people argue that control dependency cannot manifest in real code. Any help?

Answer 1

My understanding of the situation is:

a) C was designed without much/any support for memory ordering.

b) Linux developers wanted to improve performance in ways that C doesn't support

c) Linux developers constructed their own inner language from macros, non-standardized inline assembly and "implementation defined by one compiler" behavior. Let's call this the "Not C Language".

d) Linux developers found out that their "Not C Language" has corner-cases that don't comply with the intentions of their "Not C Language".

So I wonder is there any real case that is caused by control dependencies?

For programs written in C there can't be any real case where problems are caused by control dependencies; simply because you must rely on something that's guaranteed by C (e.g. proper locks) in the absence of memory ordering guarantees.

For programs written in the current version of their "Not C Language" there are theoretical cases where it is a problem (example); which is why they're adding volatile_if() to the "standard that doesn't exist" for their "Not C Language". According to Linus (here) there currently aren't any real cases of this happening in the Linux source code; and because nothing else in the world uses their "Not C Language" we can say that there currently aren't any real cases in the world.