public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>,
	       Richard Sandiford <richard.sandiford@linaro.org>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] Fix mult expansion ICE (PR middle-end/82875)
Date: Wed, 22 Nov 2017 09:26:00 -0000	[thread overview]
Message-ID: <20171122091718.GH14653@tucnak> (raw)

Hi!

On these two testcases, we end up expanding MULT_EXPR where both arguments
end up being VOIDmode.  For smul_optab that isn't a problem, we have
the mode next to it, but in some cases we want to use {u,s}mul_widen_optab
which is a conversion optab which needs two modes expand_binop is called
just with one mode, the result mode, so the other mode is guessed from
the operands and if both are VOIDmode, then a fallback is chosen to use
return mode.  The new find_widening* changes ICE on that though, previously
we'd just do something.

In any case, I think we need to make sure this doesn't happen while we
still know both modes for the {u,s}mul_widen_optab.  Bootstrapped/regtested
on x86_64-linux and i686-linux, ok for trunk?

Perhaps additionally we could have somewhere a case which for both arguments
constant (unlikely case, as the gimple optimizers should usually optimize
that out) and selected optabs for which we know the corresponding RTL code
we could use simplify_const_binary_operation and see if it optimizes into a
constant and just return that.  Though, these functions are large and it
is still possible a constant could be uncovered later, so I think we want
this patch even if we do something like that.

2017-11-22  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/82875
	* optabs.c (expand_doubleword_mult, expand_binop): Before calling
	expand_binop with *mul_widen_optab, make sure at least one of the
	operands doesn't have VOIDmode.

	* gcc.dg/pr82875.c: New test.
	* gcc.c-torture/compile/pr82875.c: New test.

--- gcc/optabs.c.jj	2017-11-09 20:23:51.000000000 +0100
+++ gcc/optabs.c	2017-11-21 17:40:13.318673366 +0100
@@ -861,6 +861,11 @@ expand_doubleword_mult (machine_mode mod
   if (target && !REG_P (target))
     target = NULL_RTX;
 
+  /* *_widen_optab needs to determine operand mode, make sure at least
+     one operand has non-VOID mode.  */
+  if (GET_MODE (op0_low) == VOIDmode && GET_MODE (op1_low) == VOIDmode)
+    op0_low = force_reg (word_mode, op0_low);
+
   if (umulp)
     product = expand_binop (mode, umul_widen_optab, op0_low, op1_low,
 			    target, 1, OPTAB_DIRECT);
@@ -1199,6 +1204,10 @@ expand_binop (machine_mode mode, optab b
 				  : smul_widen_optab),
 				 wider_mode, mode) != CODE_FOR_nothing))
     {
+      /* *_widen_optab needs to determine operand mode, make sure at least
+	 one operand has non-VOID mode.  */
+      if (GET_MODE (op0) == VOIDmode && GET_MODE (op1) == VOIDmode)
+	op0 = force_reg (mode, op0);
       temp = expand_binop (wider_mode,
 			   unsignedp ? umul_widen_optab : smul_widen_optab,
 			   op0, op1, NULL_RTX, unsignedp, OPTAB_DIRECT);
--- gcc/testsuite/gcc.dg/pr82875.c.jj	2017-11-21 17:50:16.022274628 +0100
+++ gcc/testsuite/gcc.dg/pr82875.c	2017-11-21 17:49:46.000000000 +0100
@@ -0,0 +1,11 @@
+/* PR middle-end/82875 */
+/* { dg-do compile } */
+/* { dg-options "-ftree-ter" } */
+
+const int a = 100;
+
+void
+foo (void)
+{
+  int c[a];
+}
--- gcc/testsuite/gcc.c-torture/compile/pr82875.c.jj	2017-11-21 17:48:46.409374708 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr82875.c	2017-11-21 17:48:25.000000000 +0100
@@ -0,0 +1,24 @@
+/* PR middle-end/82875 */
+
+signed char a;
+unsigned b;
+long c, d;
+long long e;
+
+void
+foo (void)
+{
+  short f = a = 6;
+  while (0)
+    while (a <= 7)
+      {
+	for (;;)
+	  ;
+	lab:
+	  while (c <= 73)
+	    ;
+	e = 20;
+	d ? (a %= c) * (e *= a ? f : b) : 0;
+      }
+  goto lab;
+}

	Jakub

             reply	other threads:[~2017-11-22  9:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22  9:26 Jakub Jelinek [this message]
2017-11-22  9:43 ` Richard Biener
2017-11-22 10:09   ` Jakub Jelinek
2017-11-22 10:16     ` Richard Biener
2017-11-22 13:34       ` Richard Sandiford
2017-11-22 13:50         ` Jakub Jelinek
2017-11-22  9:55 ` Richard Sandiford
2017-12-04  7:01 ` [testsuite, committed] Require effective target alloca for pr82875.c Tom de Vries

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=20171122091718.GH14653@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    --cc=richard.sandiford@linaro.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).