On Tue, 2015-06-09 at 10:50 +0100, Ramana Radhakrishnan wrote: > > On 22/05/15 17:56, Torvald Riegel wrote: > > On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote: > >> Hi, > >> > >> While writing atomic_word.h for the ARM backend to fix PR target/66200 > >> I > >> thought it would make more sense to write it all up with atomic > >> primitives instead of providing various fragile bits of inline > >> asssembler. Thus this patch came about. I intend to ask for a > >> specialized version of this to be applied for the ARM backend in any > >> case after testing completes. > >> > >> If this goes in as a cleanup I expect all the ports to be deleting > >> their > >> atomic_word.h implementation in the various ports directories and > >> I'll > >> follow up with patches asking port maintainers to test and apply for > >> each of the individual cases if this is deemed to be good enough. > > > > Could you use C++11 atomics right away instead of adapting the wrappers? > > > I spent some time trying to massage guard.cc into using C++11 atomics > but it was just easier to write it with the builtins - I consider this > to be a step improvement compared to where we are currently.
Fair enough. > I don't think we can remove _GLIBCXX_READ_MEM_BARRIER and > _GLIBCXX_WRITE_MEM_BARRIER from atomic_word.h even though they are > superseded by the atomics as it is published in the documentation as > available macros. I see. We should at least update the documentation of those, as the current one isn't a really portable specification. If we can, I'd deprecate them. Jonathan, what do you think? > It was obvious that alpha, powerpc, aix, ia64 could just fall back to > the standard implementations. The cris and sparc implementations have > different types for _Atomic_word from generic and the rest - my guess is > sparc can remove the _GLIBCXX_READ_MEM_BARRIER and > _GLIBCXX_WRITE_MEM_BARRIER but I have no way of testing this is sane. > > I'll leave that to the respective target maintainers for sparc and cris > to deal as appropriate. LGTM.
