https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Jonathan Wakely from comment #4) > 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? Or maybe this flag is relevant for languages that don't use the C and C++ memory models, where the rules are different?
