[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

["amacleod at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.