https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #48 from mwahab at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #47) > Created attachment 35425 [details] > 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. > I've been working on patches for this. Adding a new MEMMODEL type was my first approach because it means that gcc has one representation for all the memory models it supports. I decided not to submit the patch because Aarch64 also needs an tag for the __sync acquire used in __sync_lock_test_and_set. Adding that touches more backends than the MEMMODEL_SYNC and some of those changes are not obvious (for the mips backend in particular). The reasons why Aarch64 needs a new acquire barrier are rather tenuous (they're in the earlier comments) and don't seem to justify the possibly invasive changes that would be needed. The approach I'm working on now is to add a target hook to allow a backend to supply its own expansion of calls to the __sync builtins. That makes for smaller changes in the target-independent code and lets the Aarch64 backend add the new barriers as target-specific memory models. The actual code generation goes through the infrastructure for the atomics. Adding the __sync barriers to coretypes.h is the better approach if more than one backend has this problem. Since it seems that only Aarch64 is affected, I think its better to go with the target hook. If a new architecture gets added with the same problem, it will be easy enough to switch to the coretypes.h approach.
