[Patch libstdc++] Rewrite cpu/generic/atomic_word.h
Thu Jun 11 21:56:00 GMT 2015
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.
> 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.
More information about the Libstdc++