syzygy wrote:
Some race conditions can be detected trivially. First of all, we need to be talking C11 or talking about threads does not even make sense. In C11, just let one thread create another thread and let both threads at some point access the same variable. If there are no synchronisation primitives on the paths towards these accesses, you have a data race. C11 defines the synchronisation primitives, so the compiler can recognise their absence.
Will compilers actively look for data races? Probably not. But they can assume that they won't happen and optimise your code in ways that you certainly are not expecting.
The problem is that the only way that might work for detecting races at compile time would be static analysis. But it's very expensive and unreliable.
I very much doubt any compiler will do that.
Another possibility would be to detect races at runtime and choose appropriate code paths: this would be too expensive and wouldn't work either.
What remains is hardware that would trap on races (maybe something like that already exists, I'm no hardware expert), but this has nothing to do with the compiler.
I think this undefined behavior made it into standard for a different reason than optimizations (is there a real world example where such optimizations work/help?).
I think it's because of focusing on future advancements in hardware and most importantly because of security, but I may be wrong.
To be honest, being 100% standard compiant will become black art,
existing very large code bases will have to be rewritten completely (which will cost time and money and introduce new bugs).
I'm not sure if this is of any good. We'll see.