Fix PR c/8588

Fix PR c/8588

[Eric Botcazou]

Hi,

This is a high-priority PR, regression from 3.0.x on gcc-3_2-branch and 
mainline. The recognizer chokes on the following obviously illegal insn:

(insn 10 20 12 (set (reg:QI 58)
        (const_int 240 [0xf0])) -1 (nil)
    (nil))

The problem comes from the initial RTL generation: lshrsi3 wants a QImode 
operand for its second operand on i386. Now optabs.c contains a special 
provision in order not to convert CONST_INTs in shift operations...

The proposed fix is to get rid of this provision. Bootstrapped/regtested on 
i586-redhat-linux-gnu (c,c++,objc,f77 mainline).

-- 
Eric Botcazou


2002-11-18  Eric Botcazou  <ebotcazou@libertysurf.fr>

	* optabs.c (expand_binop): Convert CONST_INTs in
	shift operations too.


2002-11-18  Eric Botcazou  <ebotcazou@libertysurf.fr>

	* gcc.c-torture/compile/20021118-1.c: New test.


Index: optabs.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/optabs.c,v
retrieving revision 1.151
diff -u -r1.151 optabs.c
--- optabs.c	16 Nov 2002 06:08:16 -0000	1.151
+++ optabs.c	18 Nov 2002 19:50:29 -0000
@@ -781,9 +781,8 @@
       /* In case the insn wants input operands in modes different from
 	 those of the actual operands, convert the operands.  It would
 	 seem that we don't need to convert CONST_INTs, but we do, so
-	 that they're properly zero-extended or sign-extended for their
-	 modes; shift operations are an exception, because the second
-	 operand need not be extended to the mode of the result.  */
+	 that they're properly zero-extended, sign-extended or truncated
+	 for their mode.  */
 
       if (GET_MODE (op0) != mode0 && mode0 != VOIDmode)
 	xop0 = convert_modes (mode0,
@@ -796,7 +795,7 @@
 	xop1 = convert_modes (mode1,
 			      GET_MODE (op1) != VOIDmode
 			      ? GET_MODE (op1)
-			      : (shift_op ? mode1 : mode),
+			      : mode,
 			      xop1, unsignedp);
 
       /* Now, if insn's predicates don't allow our operands, put them into
@@ -2234,8 +2233,8 @@
       /* In case the insn wants input operands in modes different from
 	 those of the actual operands, convert the operands.  It would
 	 seem that we don't need to convert CONST_INTs, but we do, so
-	 that they're properly zero-extended or sign-extended for their
-	 modes.  */
+	 that they're properly zero-extended, sign-extended or truncated
+	 for their mode.  */
 
       if (GET_MODE (op0) != mode0 && mode0 != VOIDmode)
 	xop0 = convert_modes (mode0,


--- /dev/null   Thu Apr 11 16:25:15 2002
+++ gcc.c-torture/compile/20021118-1.c  Mon Nov 18 20:51:52 2002
@@ -0,0 +1,11 @@
+/* PR c/8588 */
+/* Contributed by Volker Reichelt. */
+
+/* Verify that GCC converts integer constants
+   in shift operations. */
+
+void foo()
+{
+  unsigned int i, j;
+  j = (i >> 0xf0);
+}

Re: Fix PR c/8588

[Geoff Keating]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> Hi,
> 
> This is a high-priority PR, regression from 3.0.x on gcc-3_2-branch and 
> mainline. The recognizer chokes on the following obviously illegal insn:
> 
> (insn 10 20 12 (set (reg:QI 58)
>         (const_int 240 [0xf0])) -1 (nil)
>     (nil))
> 
> The problem comes from the initial RTL generation: lshrsi3 wants a QImode 
> operand for its second operand on i386. Now optabs.c contains a special 
> provision in order not to convert CONST_INTs in shift operations...
> 
> The proposed fix is to get rid of this provision. Bootstrapped/regtested on 
> i586-redhat-linux-gnu (c,c++,objc,f77 mainline).

This patch is OK, please commit it.

> 2002-11-18  Eric Botcazou  <ebotcazou@libertysurf.fr>
> 
> 	* optabs.c (expand_binop): Convert CONST_INTs in
> 	shift operations too.
> 
> 
> 2002-11-18  Eric Botcazou  <ebotcazou@libertysurf.fr>
> 
> 	* gcc.c-torture/compile/20021118-1.c: New test.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Fix PR c/8588

[Eric Botcazou]

> This patch is OK, please commit it.

Done. OK for gcc-3_2-branch too once it is reopened ?

-- 
Eric Botcazou

Re: Fix PR c/8588

[Geoff Keating]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> > This patch is OK, please commit it.
> 
> Done. OK for gcc-3_2-branch too once it is reopened ?

Yes, OK for the branch.

-- 
- Geoffrey Keating <geoffk@geoffk.org>