https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #36 from mwahab at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #31) > > > Targets that don't need special sync patterns (ie most of them) simply don't > provide them. The expanders see no sync pattern and use SEQ_CST, exactly > like they do today. For current targets that may be true but assumes that no new target will need the special sync patterns. > sync patterns would only be provided by targets which do need to do > something different. This means there is no potential bug introduction on > unaffected targets.. I was thinking of existing sync patterns in current backends which may have been made redundant by the atomics builtins but are still there. There's a danger that they'll get used even if they're not preferred for that target. There's also the question of whether they're getting tested, assuming that they were only ever generated for the __sync builtins. > Well, it actually returns back to the situation before they were merged. We > use to look for sync patterns too... until I thought they were redundant. I believe that they are redundant (for __sync builtins anyway) since it looks like everything could be done through the atomics + new barrier. > The intention was to deprecate __sync and support just the c++ memory model. > SEQ_CST == SYNC was the original intent and understanding, thus the code > merge. If we decide we want/need to provide a stronger form of SEQ_CST and > call it SYNC, then we can do that as required... but I'm not envisioning a > lot of future additional memory models. Although never say never I suppose. I don't expect that many models will be needed, the set should certainly be kept as small as possible. I think that extending it in this case is justified because of the gap between what is needed and what is now available. The choice seems to be - between continuing the move away from the syncs to the atomics. This makes the __sync and the __atomic builtins rely on one infrastructure. - keeping both the atomics and the syncs infrastructures with individual targets choosing between them. The first option seems better, not least because it reduces the number of things that need to be understood when dealing with synchronization primitives.
