From: "Joseph S. Myers" <joseph@codesourcery.com>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: Adhemerval Zanella <azanella@linux.vnet.ibm.com>,
Richard Henderson <rth@redhat.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] PowerPC: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV
Date: Fri, 01 Aug 2014 15:31:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1408011526020.12217@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CAGWvny=FJR61ZWQsMOhJxv2OSnAgpCYVt2pDWSchiU-izArzdA@mail.gmail.com>
On Thu, 31 Jul 2014, David Edelsohn wrote:
> Thanks for implementing the FENV support. The patch generally looks
> good to me.
>
> My one concern is a detail in the implementation of "update". I do not
> have enough experience with GENERIC to verify the details and it seems
> like it is missing building an outer COMPOUND_EXPR containing
> update_mffs and the CALL_EXPR for update mtfsf.
I suppose what's actually odd there is that you have
+ tree update_mffs = build2 (MODIFY_EXPR, void_type_node, old_fenv, call_mffs);
+
+ tree old_llu = build1 (VIEW_CONVERT_EXPR, uint64_type_node, update_mffs);
so you build a MODIFY_EXPR in void_type_node but then convert it with a
VIEW_CONVERT_EXPR. If you'd built the MODIFY_EXPR in double_type_node
then the VIEW_CONVERT_EXPR would be meaningful (the value of an assignment
a = b being the new value of a), but reinterpreting a void value doesn't
make sense. Or you could probably just use call_mffs directly in the
VIEW_CONVERT_EXPR without explicitly creating the old_fenv variable.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2014-08-01 15:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 20:33 David Edelsohn
2014-08-01 3:28 ` David Edelsohn
2014-08-01 15:31 ` Joseph S. Myers [this message]
2014-08-06 20:21 ` Adhemerval Zanella
2014-08-19 16:54 ` Adhemerval Zanella
2014-09-02 22:23 ` Adhemerval Zanella
2014-09-03 14:01 ` Maciej W. Rozycki
2014-09-03 15:49 ` Joseph S. Myers
2014-09-04 18:40 ` Adhemerval Zanella
2014-09-15 14:38 ` Maciej W. Rozycki
2014-10-20 17:18 ` [PING][PATCH] GCC/test: Set timeout factor for c11-atomic-exec-5.c Maciej W. Rozycki
2014-10-21 0:26 ` David Edelsohn
2014-10-21 1:49 ` Joseph S. Myers
2014-10-21 2:15 ` David Edelsohn
2014-10-21 23:03 ` Maciej W. Rozycki
2014-11-14 21:02 ` [PING^2][PATCH] " Maciej W. Rozycki
2014-11-17 10:06 ` Mike Stump
2014-11-18 16:48 ` Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2014-09-16 21:05 [PATCH] PowerPC: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV David Edelsohn
2014-09-03 14:08 Uros Bizjak
2014-09-04 17:39 ` Maciej W. Rozycki
2014-07-03 21:09 Adhemerval Zanella
2014-07-16 18:41 ` Adhemerval Zanella
2014-07-31 1:43 ` Joseph S. Myers
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=Pine.LNX.4.64.1408011526020.12217@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=azanella@linux.vnet.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rth@redhat.com \
/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).