This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch libstdc++] Rewrite cpu/generic/atomic_word.h
- From: Torvald Riegel <triegel at redhat dot com>
- To: ramrad01 at arm dot com
- Cc: Jonathan Wakely <jwakely at redhat dot com>, Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>, "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>
- Date: Fri, 12 Jun 2015 16:35:41 +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> <1434059802 dot 15758 dot 5 dot camel at localhost dot localdomain> <20150612090651 dot GQ12728 at redhat dot com> <CAJA7tRb9zqF=7STmG5LvXcvQtBPkOmPyT93JLOCgL-ZOhqDxRQ at mail dot gmail dot com>
On Fri, 2015-06-12 at 10:30 +0100, Ramana Radhakrishnan wrote:
> On Fri, Jun 12, 2015 at 10:06 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
> > On 11/06/15 23:56 +0200, Torvald Riegel wrote:
> >>>
> >>> > On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
> >>> 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?
> >
> >
> > Yes, I'm in favour of deprecating them. They are GCC-specific anyway,
> > so there is no reason to prefer them to std::atomic_ or __atomic_
> > fences.
>
> I'll treat it as a follow-up.
Thanks.
> Can I get an ack for this patch though ?
The above comment was of a general nature, not specifically about this
patch or meant as a precondition for this patch. Sorry if that wasn't
clear :)
To me, your patch looks good.