For Linux it's specific bare-metal targets so -Werror is less evil than in general, but still a bad idea. Linux uses -fno-strict-aliasing etc. so it's not subject to most C memory model issues a new compiler could break.
Conversation
Replying to
I mean that they don't follow the C11 memory model for atomics and make extensive use of atomics. The compiler developers don't agree with their homegrown rules and don't respect them. There's a whole lot of complicated lock-free data structure stuff that's really quite fragile.
2
Replying to
Aren't they all accessed as volatiles? Assuming a C compiler with a reasonable sense of volatile, you can model your own atomics that way (other cores being async hardware modifying the volatile memory).
1
Replying to
No, they don't use volatile for that since it would hurt performance too much and the whole reason for them refusing to use C11 atomics is because they think even the acquire/release semantics are too expensive.
2
Replying to
Acquire/release are a lot more expensive than volatile. Volatile just means each load/store on the abstract machine has to translate to one on the real machine, with matching load/store size (no split/combining) where the machine admits it.
1
Replying to
Look at open-std.org/jtc1/sc22/wg21. They're got their own quite fleshed out way of doing things. They decided how C should work and fleshed that out but they aren't on the same page as the C standard or compiler authors right now. There are ongoing efforts to fix the problems.
2
Replying to
According to that they're all modeled as volatile accesses which makes them completely compatible with the C memory model assuming a compiler that implements volatile in any meaningful way (any way compatible with mmio registers, for example).
1
Replying to
Clang/GCC expect you to use volatile + atomics rather than volatile alone with the assumption that it gives atomic semantics.
1
Replying to
That is not the case. It is entirely consistent to model "other cores" or "threads running on other cores" as black-box hardware entities that modify volatile objects asynchronously. Of course you also need barriers if...
1
...if you want them to impose any kind of consistency or ordering with other loads and stores. But there's no reason you can't do that.
2
Replying to
They aren't doing that while still having expectations beyond what is guaranteed.
For the particular case of consume loads, READ_ONCE recently subsumed smp_read_barrier_depends. Earlier that was in the lockless_dereference implementation. That provides the non-tearing word sized load + required data dependency ordering on all platforms Linux runs on.
2
1
IIUC the theme in that paper was about getting stronger guarantees from the standard about things they care about (e.g. control dependencies - same store in either branch can be lifted before the load), hence the recent proposal for volatile_if in absence of a compiler solution.
1