This is the mail archive of the
mailing list for the GCC project.
Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
- From: Jason Merrill <jason at redhat dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>, David Edelsohn <dje dot gcc at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jim Wilson <wilson at tuliptree dot org>, Steve Ellcey <sellcey at mips dot com>, Richard Henderson <rth at redhat dot com>, Steve Munroe <munroesj at linux dot vnet dot ibm dot com>, Torvald Riegel <triegel at redhat dot com>
- Date: Fri, 22 May 2015 13:36:17 -0400
- Subject: Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
- Authentication-results: sourceware.org; auth=none
- References: <555F1143 dot 4070606 at foss dot arm dot com> <555F11B6 dot 1070001 at foss dot arm dot com> <555F31CF dot 6060201 at redhat dot com> <CAGWvnykzukDM2aG_QmbeCyOh7+u6xF8snOc13GUHG2RULoQU-g at mail dot gmail dot com> <555F3D09 dot 2070700 at redhat dot com> <555F49FF dot 1070402 at foss dot arm dot com>
On 05/22/2015 11:23 AM, Ramana Radhakrishnan wrote:
On 22/05/15 15:28, Jason Merrill wrote:
I do notice that get_guard_bits after build_atomic_load just won't work
on non-ARM targets, as it ends up trying to take the address of a value.
So on powerpc where targetm.guard_mask_bit is false - this is what I see.
&(long long int) __atomic_load_8 (&_ZGVZ1fvE1p, 2)
This is the bit that doesn't make sense to me. __atomic_load_8 returns
a value; what does it mean to take its address? If we're going to load
more than just the first byte, we should mask off the rest rather than
trying to mess with its address.
It also seems unnecessary to load 8 bytes on any target; we could add a
function to optabs.c that returns the smallest mode for which there's
atomic load support?