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: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: Torvald Riegel <triegel 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 10:30:01 +0100
- 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>
- Reply-to: ramrad01 at arm dot com
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.
Can I get an ack for this patch though ? I could backport this as is
to fix the problems on ARM / AArch64 (PR target/66200) - alternatively
I'll provide header implementations of the same for the release
branches.
regards
Ramana