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: Jonathan Wakely <jwakely at redhat dot com>
- To: ramrad01 at arm 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:38:24 +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> <CAJA7tRb9zqF=7STmG5LvXcvQtBPkOmPyT93JLOCgL-ZOhqDxRQ at mail dot gmail dot com>
On 12/06/15 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.
Sure.
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.
Yes, OK for trunk, thanks.
I think it's safer if the backport only changes the ARM and AArch64
implementations, at least for now. If no problems are found on trunk
we could consider backporting the whole thing for all targets, but it
may not be worth it if the other targets are working OK.