Patchwork Fix PR middle-end/52140, ICE on valid code

login
register
mail settings
Submitter Peter Bergner
Date Feb. 9, 2012, 2:34 a.m.
Message ID <1328754874.3164.13.camel@otta>
Download mbox | patch
Permalink /patch/140290/
State New
Headers show

Comments

Peter Bergner - Feb. 9, 2012, 2:34 a.m.
The following patch fixes an ICE when we try and generate a compare of
decimal float variables when we are not compiling for a cpu with dfp
hardware support.  This is a regression from gcc 4.4.  The patch below
bootstrapped and regression tested with no regressions on trunk, 4.6
and 4.5.  Is this ok everywhere?

I'll note that there seem to be a few other places that need this change,
but they aren't needed to fix this ICE, so I left them for a 4.8. cleanup.

Peter


gcc/
	PR middle-end/52140
	* dojump.c (do_compare_rtx_and_jump): Use SCALAR_FLOAT_MODE_P.

gcc/testsuite/
	PR middle-end/52140
	* gcc.dg/dfp/pr52140.c: New test.
Peter Bergner - Feb. 9, 2012, 2:38 a.m.
On Wed, 2012-02-08 at 20:34 -0600, Peter Bergner wrote:
> The following patch fixes an ICE when we try and generate a compare of
> decimal float variables when we are not compiling for a cpu with dfp
> hardware support.  This is a regression from gcc 4.4.  The patch below
> bootstrapped and regression tested with no regressions on trunk, 4.6
> and 4.5.  Is this ok everywhere?

Sorry for replying to my own message, but I meant to say this was
bootstrapped and regression tested on powerpc64-linux and running
the test suite in both 32-bit and 64-bit modes.

Peter
Richard Guenther - Feb. 9, 2012, 10:31 a.m.
On Thu, Feb 9, 2012 at 3:34 AM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> The following patch fixes an ICE when we try and generate a compare of
> decimal float variables when we are not compiling for a cpu with dfp
> hardware support.  This is a regression from gcc 4.4.  The patch below
> bootstrapped and regression tested with no regressions on trunk, 4.6
> and 4.5.  Is this ok everywhere?
>
> I'll note that there seem to be a few other places that need this change,
> but they aren't needed to fix this ICE, so I left them for a 4.8. cleanup.

Ok.

Thanks,
Richard.

> Peter
>
>
> gcc/
>        PR middle-end/52140
>        * dojump.c (do_compare_rtx_and_jump): Use SCALAR_FLOAT_MODE_P.
>
> gcc/testsuite/
>        PR middle-end/52140
>        * gcc.dg/dfp/pr52140.c: New test.
>
> Index: gcc/dojump.c
> ===================================================================
> --- gcc/dojump.c        (revision 184032)
> +++ gcc/dojump.c        (working copy)
> @@ -1049,7 +1049,7 @@ do_compare_rtx_and_jump (rtx op0, rtx op
>     }
>   else
>     {
> -      if (GET_MODE_CLASS (mode) == MODE_FLOAT
> +      if (SCALAR_FLOAT_MODE_P (mode)
>          && ! can_compare_p (code, mode, ccp_jump)
>          && can_compare_p (swap_condition (code), mode, ccp_jump))
>        {
> @@ -1060,7 +1060,7 @@ do_compare_rtx_and_jump (rtx op0, rtx op
>          op1 = tmp;
>        }
>
> -      else if (GET_MODE_CLASS (mode) == MODE_FLOAT
> +      else if (SCALAR_FLOAT_MODE_P (mode)
>               && ! can_compare_p (code, mode, ccp_jump)
>
>               /* Never split ORDERED and UNORDERED.  These must be implemented.  */
> Index: gcc/testsuite/gcc.dg/dfp/pr52140.c
> ===================================================================
> --- gcc/testsuite/gcc.dg/dfp/pr52140.c  (revision 0)
> +++ gcc/testsuite/gcc.dg/dfp/pr52140.c  (revision 0)
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O1" } */
> +
> +/* This used to result in an ICE.  */
> +
> +int
> +foo (_Decimal64 x, _Decimal64 y)
> +{
> +  return (x < y) || (x > y);
> +}
>
>
Peter Bergner - Feb. 9, 2012, 3:08 p.m.
On Thu, 2012-02-09 at 11:31 +0100, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 3:34 AM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> > The following patch fixes an ICE when we try and generate a compare of
> > decimal float variables when we are not compiling for a cpu with dfp
> > hardware support.  This is a regression from gcc 4.4.  The patch below
> > bootstrapped and regression tested with no regressions on trunk, 4.6
> > and 4.5.  Is this ok everywhere?
>
> Ok.

Committed on trunk and both branches.  Thanks.

Peter

Patch

Index: gcc/dojump.c
===================================================================
--- gcc/dojump.c	(revision 184032)
+++ gcc/dojump.c	(working copy)
@@ -1049,7 +1049,7 @@  do_compare_rtx_and_jump (rtx op0, rtx op
     }
   else
     {
-      if (GET_MODE_CLASS (mode) == MODE_FLOAT
+      if (SCALAR_FLOAT_MODE_P (mode)
 	  && ! can_compare_p (code, mode, ccp_jump)
 	  && can_compare_p (swap_condition (code), mode, ccp_jump))
 	{
@@ -1060,7 +1060,7 @@  do_compare_rtx_and_jump (rtx op0, rtx op
 	  op1 = tmp;
 	}
 
-      else if (GET_MODE_CLASS (mode) == MODE_FLOAT
+      else if (SCALAR_FLOAT_MODE_P (mode)
 	       && ! can_compare_p (code, mode, ccp_jump)
 
 	       /* Never split ORDERED and UNORDERED.  These must be implemented.  */
Index: gcc/testsuite/gcc.dg/dfp/pr52140.c
===================================================================
--- gcc/testsuite/gcc.dg/dfp/pr52140.c	(revision 0)
+++ gcc/testsuite/gcc.dg/dfp/pr52140.c	(revision 0)
@@ -0,0 +1,10 @@ 
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+/* This used to result in an ICE.  */
+
+int
+foo (_Decimal64 x, _Decimal64 y)
+{
+  return (x < y) || (x > y);
+}