[Patch libstdc++] Rewrite cpu/generic/atomic_word.h

[Torvald Riegel]

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.