https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- I think this is still unclear. What does "new data races" mean? Can it introduce races in code that had none previously? Or only add new ones to code that already has them? Does this make -Ofast incompatible with multithreaded programs? Does this only apply to non-atomic loads and stores? If all accesses to a variable use atomic ops, does that mean it's immune from the unsafe optimizations enabled by this flag? If no, that makes -Ofast unusable in MT code. If yes, good, but why is the flag needed? If there are non-atomic accesses to a variable, we can already assume it's not concurrently accessed, because any such potentially concurrent conflicting action would already be a data race and UB. If we already have data races with UB, can't we just introduce more? Is this flag saying "allow the compiler to make existing UB even worse"? If not, what is it saying?
