This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch libstdc++] Rewrite cpu/generic/atomic_word.h
- From: Torvald Riegel <triegel at redhat dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, David Edelsohn <dje dot gcc at gmail dot com>, hp at axis dot com, Steve Ellcey <sellcey at mips dot com>, Jim Wilson <jim dot wilson at linaro dot org>, Jonathan Wakely <jwakely at redhat dot com>
- Date: Thu, 11 Jun 2015 23:56:42 +0200
- Subject: Re: [Patch libstdc++] Rewrite cpu/generic/atomic_word.h
- Authentication-results: sourceware.org; auth=none
- References: <555F14F1 dot 2090504 at foss dot arm dot com> <1432313791 dot 3077 dot 8 dot camel at triegel dot csb> <5576B6D5 dot 5010209 at foss dot arm dot com>
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.