https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #25 from Andrew Macleod <amacleod at redhat dot com> --- My opinion: 1) is undesirable... even though it could possibly accelerate the conversion of legacy sync to atomic calls... I fear it would instead just cause frustration, annoyance and worse. I don't think we need to actually penalize sync for no reason better than a 1 in a somethillion shot in the dark. 2) Similar reasoning, I don't think we need to penalize SEQ_CST everywhere for a legacy sync call that probably doesn't need stronger code either. which leaves option 3) There are 2 primary options I think a) introduce an additional memory model... MEMMODEL_SYNC or something which is even stronger than SEQ_CST. This would involve fixing any places that assume SEQ_CST is the highest. And then we use this from the places that expand sync calls as the memory model. or b) When we are expanding sync calls, we first look for target __sync patterns instead of atomic patterns. If they exist, we use those. Otherwise we simply expand like we do today. (b) may be easier to implement, but puts more onus on the target.. probably involves more complex patterns since you need both atomic and sync patterns. My guess is some duplication of code will occur here. But the impact is only to specific targets. (a) Is probably cleaner... just touches a lot more code. Since we're in stage 1, maybe (a) is a better long term solution...? Documentation needs updating for sure... The rules have changed under us since originally SEQ_CST and sync were intended to be the same thing... Guess I shouldn't have tied our horse to the C++11 cart :-)
