From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>, Nathan Sidwell <nathan@acm.org>
Cc: gcc-patches@gcc.gnu.org
Subject: [C++ PATCH] Optimize void COND_EXPRs during cp_fold (PR c++/81675)
Date: Fri, 24 Nov 2017 21:42:00 -0000 [thread overview]
Message-ID: <20171124213500.GA14653@tucnak> (raw)
Hi!
The comment says that trying to fold VOID_TYPE_P COND_EXPRs is not worth
bothering, but as the following testcase shows, that is not the case.
fold_ternary can optimize COND_EXPRs where the condition is constant and
the unused branch doesn't have any labels, and not folding it early means
bogus warnings afterwards.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2017-11-24 Jakub Jelinek <jakub@redhat.com>
PR c++/81675
* cp-gimplify.c (cp_fold) <case COND_EXPR>: Don't return immediately
for VOID_TYPE_P COND_EXPRs, instead fold the operands and if op0 is
INTEGER_CST, ensure that both op1 and op2 are non-NULL and fall
through into normal folding, otherwise just rebuild x if any op
changed.
* g++.dg/warn/pr81675.C: New test.
--- gcc/cp/cp-gimplify.c.jj 2017-11-21 20:23:01.000000000 +0100
+++ gcc/cp/cp-gimplify.c 2017-11-24 11:09:51.879647584 +0100
@@ -2299,13 +2299,6 @@ cp_fold (tree x)
case VEC_COND_EXPR:
case COND_EXPR:
-
- /* Don't bother folding a void condition, since it can't produce a
- constant value. Also, some statement-level uses of COND_EXPR leave
- one of the branches NULL, so folding would crash. */
- if (VOID_TYPE_P (TREE_TYPE (x)))
- return x;
-
loc = EXPR_LOCATION (x);
op0 = cp_fold_rvalue (TREE_OPERAND (x, 0));
op1 = cp_fold (TREE_OPERAND (x, 1));
@@ -2319,6 +2312,29 @@ cp_fold (tree x)
if (!VOID_TYPE_P (TREE_TYPE (op2)))
op2 = cp_truthvalue_conversion (op2);
}
+ else if (VOID_TYPE_P (TREE_TYPE (x)))
+ {
+ if (TREE_CODE (op0) == INTEGER_CST)
+ {
+ /* If the condition is constant, fold can fold away
+ the COND_EXPR. If some statement-level uses of COND_EXPR
+ have one of the branches NULL, avoid folding crash. */
+ if (!op1)
+ op1 = build_empty_stmt (loc);
+ if (!op2)
+ op2 = build_empty_stmt (loc);
+ }
+ else
+ {
+ /* Otherwise, don't bother folding a void condition, since
+ it can't produce a constant value. */
+ if (op0 != TREE_OPERAND (x, 0)
+ || op1 != TREE_OPERAND (x, 1)
+ || op2 != TREE_OPERAND (x, 2))
+ x = build3_loc (loc, code, TREE_TYPE (x), op0, op1, op2);
+ break;
+ }
+ }
if (op0 != TREE_OPERAND (x, 0)
|| op1 != TREE_OPERAND (x, 1)
--- gcc/testsuite/g++.dg/warn/pr81675.C.jj 2017-11-24 11:12:13.962912829 +0100
+++ gcc/testsuite/g++.dg/warn/pr81675.C 2017-11-24 11:11:56.000000000 +0100
@@ -0,0 +1,15 @@
+// PR c++/81675
+// { dg-do compile }
+// { dg-options "-Wall" }
+
+struct S
+{
+ ~S () __attribute__((noreturn));
+ int a;
+};
+
+int
+foo ()
+{
+ false ? 5 : S ().a;
+}
Jakub
next reply other threads:[~2017-11-24 21:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-24 21:42 Jakub Jelinek [this message]
2017-11-27 12:44 ` Nathan Sidwell
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=20171124213500.GA14653@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=nathan@acm.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).