From: Jason Merrill <jason@redhat.com>
To: Ramana Radhakrishnan <ramana.radhakrishnan@foss.arm.com>,
David Edelsohn <dje.gcc@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Jim Wilson <wilson@tuliptree.org>,
Steve Ellcey <sellcey@mips.com>,
Richard Henderson <rth@redhat.com>,
Steve Munroe <munroesj@linux.vnet.ibm.com>,
Torvald Riegel <triegel@redhat.com>
Subject: Re: [RFC / CFT] PR c++/66192 - Remove TARGET_RELAXED_ORDERING and use load acquires.
Date: Fri, 22 May 2015 18:19:00 -0000 [thread overview]
Message-ID: <555F6911.6030205@redhat.com> (raw)
In-Reply-To: <555F49FF.1070402@foss.arm.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?
Jason
next prev parent reply other threads:[~2015-05-22 17:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-22 11:26 Ramana Radhakrishnan
2015-05-22 11:37 ` Ramana Radhakrishnan
2015-05-22 13:49 ` Jason Merrill
2015-05-22 14:15 ` David Edelsohn
2015-05-22 14:42 ` Jason Merrill
2015-05-22 15:42 ` Ramana Radhakrishnan
2015-05-22 17:48 ` David Edelsohn
2015-05-22 18:19 ` Jason Merrill [this message]
2015-05-22 19:49 ` Richard Henderson
2015-05-29 13:32 ` Ramana Radhakrishnan
2015-05-29 16:34 ` Richard Henderson
2015-05-29 16:36 ` Richard Henderson
2015-05-29 20:53 ` Jason Merrill
2015-06-04 9:46 ` Ramana Radhakrishnan
2015-06-02 14:42 ` David Edelsohn
2015-05-22 14:28 ` Ramana Radhakrishnan
2015-05-24 18:55 Uros Bizjak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555F6911.6030205@redhat.com \
--to=jason@redhat.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=munroesj@linux.vnet.ibm.com \
--cc=ramana.radhakrishnan@foss.arm.com \
--cc=rth@redhat.com \
--cc=sellcey@mips.com \
--cc=triegel@redhat.com \
--cc=wilson@tuliptree.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).