https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #47 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 35425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35425&action=edit potential patch to add MEMMODEL_SYNC I don't know where we've finally settled on this, but I did prototype out what involved in adding a new MEMMODEL_SYNC which can be identified and made stronger than MEMMODEL_SEQ_CST if so desired. Normally it will behave exactly like MEMMODEL_SEQ_CST. This bootstraps on x86-64 with no testsuite regressions. Other than using the new memmodel in the expanders for __sync routines, there were 3 common idioms that needed changing: - a few places assumed SEQ_CST was the end of the enumeration, changed those to check for MEMMODEL_LAST instead. - if (model == MEMMODEL_SEQ_CST) needed changing to if (model >= MEMMODEL_SEQ_CST) - case MEMMODEL_SEQ_CST: needed a CASE MEMMODEL_SYNC: added. Its actually not that invasive, and should have no impact on any existing target. If a target feels they need to strengthen the __sync cases, then they can look for MEMMODEL_SYNC in their rtl atomic patterns and do something different. I did a quick and dirty test on x86_64 to make the atomic_sub pattern issue an extra lock if it sees MEMMODEL_SYNC.. and that worked fine. MEMMODEL_SYNC is not exposed in any way to the user, it is only generated from the __sync expanders, and the compare_swap loop generator. If someone wants to fool around with it and see if this resolves their issues, go for it. If we decide we don't need to support a stronger __sync model and leave things as originally intended, then we simply don't use the patch. If we do decide to go ahead with it, I will also do a comparison run on the __sync tests in the testsuite to verify that the code generated is in fact identical and I didn't miss anything.
