public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-06-02 13:06 Glen Nakamura
0 siblings, 0 replies; 16+ messages in thread
From: Glen Nakamura @ 2002-06-02 13:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Glen Nakamura <glen@imodulo.com>
To: Richard Henderson <rth@redhat.com>,
Eric Botcazou <ebotcazou@libertysurf.fr>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org
Cc:
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Sun, 2 Jun 2002 10:02:44 -1000
On Sun, Jun 02, 2002 at 12:27:26PM -0700, Richard Henderson wrote:
> On Tue, May 28, 2002 at 05:33:01PM -1000, Glen Nakamura wrote:
> > * fold-const.c (fold): Modify the transformation of a comparison
> > against the highest or lowest integer value to adjust for the
> > previous transformation which converts 'X >= CST to X > (CST - 1)'
> > and 'X < CST to X <= (CST - 1)'.
>
> Would you update this for mainline? I believe we fixed the
> regression for the branch another way, but if there are
> valid simplifications we're missing...
>
Okay, I'll do that... As you pointed out earlier, PR6822 was really a
different problem. I'll update the patch for the mainline and open a new
PR to track the discussion. Then, you can decide if it's worth it for
the branch or not.
- Glen Nakamura
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-06-02 12:36 Richard Henderson
0 siblings, 0 replies; 16+ messages in thread
From: Richard Henderson @ 2002-06-02 12:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Glen Nakamura <glen@imodulo.com>
Cc: Eric Botcazou <ebotcazou@libertysurf.fr>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Sun, 2 Jun 2002 12:27:26 -0700
On Tue, May 28, 2002 at 05:33:01PM -1000, Glen Nakamura wrote:
> * fold-const.c (fold): Modify the transformation of a comparison
> against the highest or lowest integer value to adjust for the
> previous transformation which converts 'X >= CST to X > (CST - 1)'
> and 'X < CST to X <= (CST - 1)'.
Would you update this for mainline? I believe we fixed the
regression for the branch another way, but if there are
valid simplifications we're missing...
r~
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-30 16:56 rth
0 siblings, 0 replies; 16+ messages in thread
From: rth @ 2002-05-30 16:56 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, glen, nobody
Synopsis: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
State-Changed-From-To: analyzed->closed
State-Changed-By: rth
State-Changed-When: Thu May 30 16:27:01 2002
State-Changed-Why:
http://gcc.gnu.org/ml/gcc-patches/2002-05/msg02491.html
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6822
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-29 12:16 Richard Henderson
0 siblings, 0 replies; 16+ messages in thread
From: Richard Henderson @ 2002-05-29 12:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Glen Nakamura <glen@imodulo.com>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Wed, 29 May 2002 10:31:37 -0700
Amend that last.
On Wed, May 29, 2002 at 06:11:10PM +0200, Eric Botcazou wrote:
> /* When the compare code is not LTU or GEU, we can not use sbbl case.
> In case comparsion is done with immediate, we can convert it to LTU or
> GEU by altering the integer. */
>
> if ((code == LEU || code == GTU)
> && GET_CODE (ix86_compare_op1) == CONST_INT
> && mode != HImode
> && (unsigned int) INTVAL (ix86_compare_op1) != 0xffffffff
Should be checking vs GET_MODE_MASK here.
> /* The operand still must be representable as sign extended value. */
> && (!TARGET_64BIT
> || GET_MODE (ix86_compare_op0) != DImode
> || (unsigned int) INTVAL (ix86_compare_op1) != 0x7fffffff)
This clause I don't understand. We've got an unsigned comparison,
so why is INT_MAX (as opposed to UINT_MAX) interesting at all?
Unless there's something about x86-64 immediate operands? Yes,
that's it. See x86_64_sign_extended_value. In order to avoid
confusion, this comment should be changed to read
/* For x86-64, the immediate field in the instruction is 32-bit
signed, so we can't increment a DImode value above 0x7fffffff. */
> ix86_compare_op1 = GEN_INT (INTVAL (ix86_compare_op1) + 1);
And then clearly this should use gen_int_mode.
r~
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-29 10:36 Richard Henderson
0 siblings, 0 replies; 16+ messages in thread
From: Richard Henderson @ 2002-05-29 10:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Glen Nakamura <glen@imodulo.com>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Wed, 29 May 2002 10:14:10 -0700
On Wed, May 29, 2002 at 06:11:10PM +0200, Eric Botcazou wrote:
> ix86_compare_op1 = GEN_INT (INTVAL (ix86_compare_op1) + 1);
Should be using gen_int_mode here.
r~
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-29 9:44 Glen Nakamura
0 siblings, 0 replies; 16+ messages in thread
From: Glen Nakamura @ 2002-05-29 9:44 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Glen Nakamura <glen@imodulo.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Richard Henderson <rth@redhat.com>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Wed, 29 May 2002 06:31:32 -1000
On Wed, May 29, 2002 at 06:11:10PM +0200, Eric Botcazou wrote:
> --- gcc/config/i386/i386.c.orig Wed May 29 17:14:21 2002
> +++ gcc/config/i386/i386.c Wed May 29 17:28:45 2002
> @@ -7963,6 +7963,8 @@
> && (!TARGET_64BIT
> || GET_MODE (ix86_compare_op0) != DImode
> || (unsigned int) INTVAL (ix86_compare_op1) != 0x7fffffff)
> + && (GET_MODE (ix86_compare_op0) != QImode
> + || (unsigned int) INTVAL (ix86_compare_op1) != 0x7f)
> && GET_CODE (operands[2]) == CONST_INT
> && GET_CODE (operands[3]) == CONST_INT)
> {
Does this also fix the short case? e.g. 0x7fff
unsigned short
foo ()
{
return 0x8000;
}
int
main ()
{
unsigned short q = foo ();
return (q < 0x8000) ? 64 : 0;
}
BTW, Thanks for looking into this!
- Glen Nakamura
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-29 9:16 Eric Botcazou
0 siblings, 0 replies; 16+ messages in thread
From: Eric Botcazou @ 2002-05-29 9:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: "Eric Botcazou" <ebotcazou@libertysurf.fr>
To: "Richard Henderson" <rth@redhat.com>
Cc: "Glen Nakamura" <glen@imodulo.com>,
<gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Wed, 29 May 2002 18:11:10 +0200
> The problem is that +128 is not a valid QImode constant.
> It should have been rendered as -128. This should have
> happened during the conversion to rtl, not in the tree
> folding code that Eric touched.
The conversion from +127 into +128 happens here: (sorry for the ill-formatting)
config/i386/i386.c:
int
ix86_expand_int_movcc (operands)
rtx operands[];
{
enum rtx_code code = GET_CODE (operands[1]), compare_code;
rtx compare_seq, compare_op;
rtx second_test, bypass_test;
enum machine_mode mode = GET_MODE (operands[0]);
/* When the compare code is not LTU or GEU, we can not use sbbl case.
In case comparsion is done with immediate, we can convert it to LTU or
GEU by altering the integer. */
if ((code == LEU || code == GTU)
&& GET_CODE (ix86_compare_op1) == CONST_INT
&& mode != HImode
&& (unsigned int) INTVAL (ix86_compare_op1) != 0xffffffff
/* The operand still must be representable as sign extended value. */
&& (!TARGET_64BIT
|| GET_MODE (ix86_compare_op0) != DImode
|| (unsigned int) INTVAL (ix86_compare_op1) != 0x7fffffff)
&& (GET_MODE (ix86_compare_op0) != QImode
|| (unsigned int) INTVAL (ix86_compare_op1) != 0x7f)
&& GET_CODE (operands[2]) == CONST_INT
&& GET_CODE (operands[3]) == CONST_INT)
{
if (code == LEU)
code = LTU;
else
code = GEU;
ix86_compare_op1 = GEN_INT (INTVAL (ix86_compare_op1) + 1);
}
As an evidence, the following 2-line patch lets the ICE vanish:
--- gcc/config/i386/i386.c.orig Wed May 29 17:14:21 2002
+++ gcc/config/i386/i386.c Wed May 29 17:28:45 2002
@@ -7963,6 +7963,8 @@
&& (!TARGET_64BIT
|| GET_MODE (ix86_compare_op0) != DImode
|| (unsigned int) INTVAL (ix86_compare_op1) != 0x7fffffff)
+ && (GET_MODE (ix86_compare_op0) != QImode
+ || (unsigned int) INTVAL (ix86_compare_op1) != 0x7f)
&& GET_CODE (operands[2]) == CONST_INT
&& GET_CODE (operands[3]) == CONST_INT)
{
What's your diagnosis ?
--
Eric Botcazou
ebotcazou@multimania.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-29 0:46 Glen Nakamura
0 siblings, 0 replies; 16+ messages in thread
From: Glen Nakamura @ 2002-05-29 0:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Glen Nakamura <glen@imodulo.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Richard Henderson <rth@redhat.com>, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Tue, 28 May 2002 17:33:01 -1000
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6822
Here is the updated patch...
2002-05-28 Glen Nakamura <glen@imodulo.com>
* fold-const.c (fold): Modify the transformation of a comparison
against the highest or lowest integer value to adjust for the
previous transformation which converts 'X >= CST to X > (CST - 1)'
and 'X < CST to X <= (CST - 1)'.
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fold2.diff"
Index: fold-const.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.185.2.2
diff -c -3 -p -u -r1.185.2.2 fold-const.c
--- fold-const.c 23 Apr 2002 23:20:00 -0000 1.185.2.2
+++ fold-const.c 29 May 2002 03:04:20 -0000
@@ -6490,7 +6490,14 @@ fold (expr)
}
}
- /* Change X >= CST to X > (CST - 1) if CST is positive. */
+ /* Change X >= CST to X > (CST - 1) and X < CST to X <= (CST - 1)
+ if CST is positive. This transformation affects the cases which are
+ handled in later optimizations involving comparisons with non-negative
+ constants. Remember to handle the equivalent > and <= cases instead
+ of the >= and < cases. Refer to the optimizations involving
+ comparisons with 0 and comparisons with the highest possible integer
+ of a specified type below for details of how this transformation
+ affects them. */
if (TREE_CODE (arg1) == INTEGER_CST
&& TREE_CODE (arg0) != INTEGER_CST
&& tree_int_cst_sgn (arg1) > 0)
@@ -6702,7 +6709,11 @@ fold (expr)
}
}
- /* An unsigned comparison against 0 can be simplified. */
+ /* An unsigned comparison against 0 can be simplified.
+ This optimization also applies to X >= 1 and X < 1 since those cases
+ are converted to X > 0 and X <= 0 by a previous transformation
+ which changes X >= CST to X > (CST - 1) and X < CST to X <= (CST - 1)
+ if CST is positive. */
if (integer_zerop (arg1)
&& (INTEGRAL_TYPE_P (TREE_TYPE (arg1))
|| POINTER_TYPE_P (TREE_TYPE (arg1)))
@@ -6754,6 +6765,7 @@ fold (expr)
convert (type, integer_zero_node),
arg0);
case GE_EXPR:
+ code = EQ_EXPR;
TREE_SET_CODE (t, EQ_EXPR);
break;
@@ -6762,16 +6774,45 @@ fold (expr)
convert (type, integer_one_node),
arg0);
case LT_EXPR:
+ code = NE_EXPR;
TREE_SET_CODE (t, NE_EXPR);
break;
+ /* The GE_EXPR and LT_EXPR cases above are not normally
+ reached because a previous transformation changes
+ X >= CST to X > (CST - 1) and X < CST to X <= (CST - 1)
+ if CST is positive. The two new cases are handled
+ in the next switch statement. */
+
+ default:
+ break;
+ }
+
+ else if (TREE_INT_CST_HIGH (arg1) == 0
+ && (TREE_INT_CST_LOW (arg1)
+ == ((unsigned HOST_WIDE_INT) 1 << (width - 1)) - 2)
+ && ! TREE_UNSIGNED (TREE_TYPE (arg1)))
+ switch (TREE_CODE (t))
+ {
+ case GT_EXPR:
+ code = EQ_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
+ break;
+
+ case LE_EXPR:
+ code = NE_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
+ break;
+
default:
break;
}
else if (TREE_INT_CST_HIGH (arg1) == -1
&& (TREE_INT_CST_LOW (arg1)
- == ((unsigned HOST_WIDE_INT) 1 << (width - 1)))
+ == ((unsigned HOST_WIDE_INT) -1 << (width - 1)))
&& ! TREE_UNSIGNED (TREE_TYPE (arg1)))
switch (TREE_CODE (t))
{
@@ -6780,6 +6821,7 @@ fold (expr)
convert (type, integer_zero_node),
arg0);
case LE_EXPR:
+ code = EQ_EXPR;
TREE_SET_CODE (t, EQ_EXPR);
break;
@@ -6788,6 +6830,7 @@ fold (expr)
convert (type, integer_one_node),
arg0);
case GT_EXPR:
+ code = NE_EXPR;
TREE_SET_CODE (t, NE_EXPR);
break;
@@ -6804,12 +6847,18 @@ fold (expr)
switch (TREE_CODE (t))
{
case LE_EXPR:
+ /* This case also applies to X < (1 << (width - 1))
+ since a previous transformation changes
+ X < CST to X <= (CST - 1) if CST is positive. */
return fold (build (GE_EXPR, type,
convert (signed_type (TREE_TYPE (arg0)),
arg0),
convert (signed_type (TREE_TYPE (arg1)),
integer_zero_node)));
case GT_EXPR:
+ /* This case also applies to X >= (1 << (width - 1))
+ since a previous transformation changes
+ X >= CST to X > (CST - 1) if CST is positive. */
return fold (build (LT_EXPR, type,
convert (signed_type (TREE_TYPE (arg0)),
arg0),
@@ -6831,6 +6880,7 @@ fold (expr)
convert (type, integer_zero_node),
arg0);
case GE_EXPR:
+ code = EQ_EXPR;
TREE_SET_CODE (t, EQ_EXPR);
break;
@@ -6839,7 +6889,36 @@ fold (expr)
convert (type, integer_one_node),
arg0);
case LT_EXPR:
+ code = NE_EXPR;
TREE_SET_CODE (t, NE_EXPR);
+ break;
+
+ /* The GE_EXPR and LT_EXPR cases above are not normally
+ reached because a previous transformation changes
+ X >= CST to X > (CST - 1) and X < CST to X <= (CST - 1)
+ if CST is positive. The two new cases are handled
+ in the next switch statement. */
+
+ default:
+ break;
+ }
+
+ else if (TREE_INT_CST_HIGH (arg1) == 0
+ && (TREE_INT_CST_LOW (arg1)
+ == ((unsigned HOST_WIDE_INT) 2 << (width - 1)) - 2)
+ && TREE_UNSIGNED (TREE_TYPE (arg1)))
+ switch (TREE_CODE (t))
+ {
+ case GT_EXPR:
+ code = EQ_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
+ break;
+
+ case LE_EXPR:
+ code = NE_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
break;
default:
--1yeeQ81UyVL57Vl7--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-28 18:16 Glen Nakamura
0 siblings, 0 replies; 16+ messages in thread
From: Glen Nakamura @ 2002-05-28 18:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Glen Nakamura <glen@imodulo.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Tue, 28 May 2002 14:36:40 -1000
On Wed, May 29, 2002 at 01:29:35AM +0200, Eric Botcazou wrote:
> May I suggest you to add thorough cross-comments to the code ? I see you did
> so for the second optimization and I think it would be nice to do it for the
> first one too (saying that the current location of the optimization causes
> the second one to be altered).
I'll add a few comments and post an updated patch...
> It looks like this doesn't fit with the GCC policy on the matter, but it
> could also be worth leaving the original code inside an #if 0/#endif or a
> comment.
Hmm, I suppose we could just leave the original code intact. I couldn't
think of a case when it would actually be reached, but it's not a
lot of code and maybe I overlooked something. Anyway, in the future,
perhaps changes in the folding code will expose those cases?
- Glen Nakamura
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-28 17:16 Eric Botcazou
0 siblings, 0 replies; 16+ messages in thread
From: Eric Botcazou @ 2002-05-28 17:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: "Eric Botcazou" <ebotcazou@libertysurf.fr>
To: "Richard Henderson" <rth@redhat.com>,
"Glen Nakamura" <glen@imodulo.com>
Cc: <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Wed, 29 May 2002 01:43:19 +0200
> The problem is that +128 is not a valid QImode constant.
> It should have been rendered as -128. This should have
> happened during the conversion to rtl, not in the tree
> folding code that Eric touched.
>
> That's not to say that his patch didn't expose a latent bug...
I'll try to investigate this issue tomorrow.
--
Eric Botcazou
ebotcazou@multimania.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-28 16:36 Eric Botcazou
0 siblings, 0 replies; 16+ messages in thread
From: Eric Botcazou @ 2002-05-28 16:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: "Eric Botcazou" <ebotcazou@libertysurf.fr>
To: "Glen Nakamura" <glen@imodulo.com>
Cc: <gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Wed, 29 May 2002 01:29:35 +0200
> Previously, unsigned X < 128 would be converted to unsigned X <= 127 and
> then optimized to signed X >= 0. After changing the order of the
> transformations, the compiler only reduces the expression to X <= 127 ???
> The result is the reported ICE. This could very well be a latent bug
> in other parts of the compiler, but it seems the change results in missed
> opportunities to simplify expressions. I'll post an alternative patch
> in my next message...
I was almost sure to have checked the cross-dependencies between the various
blocks of code, but I overlooked this 'unsigned <= 0x7fffffff' thing... Your
patch is obviously better than mine in order to fix this chicken-and-egg
problem.
May I suggest you to add thorough cross-comments to the code ? I see you did
so for the second optimization and I think it would be nice to do it for the
first one too (saying that the current location of the optimization causes
the second one to be altered).
It looks like this doesn't fit with the GCC policy on the matter, but it
could also be worth leaving the original code inside an #if 0/#endif or a
comment.
--
Eric Botcazou
ebotcazou@multimania.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-28 11:00 Richard Henderson
0 siblings, 0 replies; 16+ messages in thread
From: Richard Henderson @ 2002-05-28 11:00 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Glen Nakamura <glen@imodulo.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Tue, 28 May 2002 10:53:15 -0700
On Tue, May 28, 2002 at 03:54:54AM -1000, Glen Nakamura wrote:
> I believe the following patch is the cause of this PR:
>
> 2002-05-15 Eric Botcazou <ebotcazou@multimania.com>
>
> * fold-const.c (fold) [LT_EXPR]: Move the transformation of a
I doubt it.
The problem is that +128 is not a valid QImode constant.
It should have been rendered as -128. This should have
happened during the conversion to rtl, not in the tree
folding code that Eric touched.
That's not to say that his patch didn't expose a latent bug...
r~
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-28 8:16 Glen Nakamura
0 siblings, 0 replies; 16+ messages in thread
From: Glen Nakamura @ 2002-05-28 8:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Glen Nakamura <glen@imodulo.com>
To: gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Tue, 28 May 2002 04:49:41 -1000
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6822
2002-05-28 Glen Nakamura <glen@imodulo.com>
* fold-const.c (fold): Modify the transformation of a comparison
against the highest or lowest integer value to adjust for the
previous transformation which converts 'X >= CST to X > (CST - 1)'
and 'X < CST to X <= (CST - 1)'.
The patch allows the compiler to reduce unsigned X < ~0 to X != ~0.
It also reduces unsigned X <= (~0 - 1) to X != ~0 which the original patch
missed... e.g. gcc.c-torture/execute/loop-2c.c execution, -Os
would fail again on i586-pc-linux-gnu if we changed:
for (p = &a[b], i = b; --i < ~0; )
*--p = i * 3 + o;
to:
for (p = &a[b], i = b; --i <= (~0 - 1); )
*--p = i * 3 + o;
With this patch, both cases should work...
- Glen Nakamura
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fold.diff"
Index: fold-const.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.185.2.2
diff -c -3 -p -r1.185.2.2 fold-const.c
*** fold-const.c 23 Apr 2002 23:20:00 -0000 1.185.2.2
--- fold-const.c 27 May 2002 21:11:18 -0000
*************** fold (expr)
*** 6490,6496 ****
}
}
! /* Change X >= CST to X > (CST - 1) if CST is positive. */
if (TREE_CODE (arg1) == INTEGER_CST
&& TREE_CODE (arg0) != INTEGER_CST
&& tree_int_cst_sgn (arg1) > 0)
--- 6490,6497 ----
}
}
! /* Change X >= CST to X > (CST - 1) and X < CST to X <= (CST - 1)
! if CST is positive. */
if (TREE_CODE (arg1) == INTEGER_CST
&& TREE_CODE (arg0) != INTEGER_CST
&& tree_int_cst_sgn (arg1) > 0)
*************** fold (expr)
*** 6753,6777 ****
return omit_one_operand (type,
convert (type, integer_zero_node),
arg0);
- case GE_EXPR:
- TREE_SET_CODE (t, EQ_EXPR);
- break;
-
case LE_EXPR:
return omit_one_operand (type,
convert (type, integer_one_node),
arg0);
! case LT_EXPR:
! TREE_SET_CODE (t, NE_EXPR);
break;
default:
break;
}
else if (TREE_INT_CST_HIGH (arg1) == -1
&& (TREE_INT_CST_LOW (arg1)
! == ((unsigned HOST_WIDE_INT) 1 << (width - 1)))
&& ! TREE_UNSIGNED (TREE_TYPE (arg1)))
switch (TREE_CODE (t))
{
--- 6754,6796 ----
return omit_one_operand (type,
convert (type, integer_zero_node),
arg0);
case LE_EXPR:
return omit_one_operand (type,
convert (type, integer_one_node),
arg0);
!
! /* The GE_EXPR and LT_EXPR cases are unnecessary because a
! previous optimization converted X >= CST to X > (CST - 1)
! and X < CST to X <= (CST - 1). These two cases are handled
! in the next switch statement. */
!
! default:
break;
+ }
+ else if (TREE_INT_CST_HIGH (arg1) == 0
+ && (TREE_INT_CST_LOW (arg1)
+ == ((unsigned HOST_WIDE_INT) 1 << (width - 1)) - 2)
+ && ! TREE_UNSIGNED (TREE_TYPE (arg1)))
+ switch (TREE_CODE (t))
+ {
+ case GT_EXPR:
+ code = EQ_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
+ break;
+ case LE_EXPR:
+ code = NE_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
+ break;
default:
break;
}
else if (TREE_INT_CST_HIGH (arg1) == -1
&& (TREE_INT_CST_LOW (arg1)
! == ((unsigned HOST_WIDE_INT) -1 << (width - 1)))
&& ! TREE_UNSIGNED (TREE_TYPE (arg1)))
switch (TREE_CODE (t))
{
*************** fold (expr)
*** 6780,6785 ****
--- 6799,6805 ----
convert (type, integer_zero_node),
arg0);
case LE_EXPR:
+ code = EQ_EXPR;
TREE_SET_CODE (t, EQ_EXPR);
break;
*************** fold (expr)
*** 6788,6793 ****
--- 6808,6814 ----
convert (type, integer_one_node),
arg0);
case GT_EXPR:
+ code = NE_EXPR;
TREE_SET_CODE (t, NE_EXPR);
break;
*************** fold (expr)
*** 6830,6847 ****
return omit_one_operand (type,
convert (type, integer_zero_node),
arg0);
- case GE_EXPR:
- TREE_SET_CODE (t, EQ_EXPR);
- break;
-
case LE_EXPR:
return omit_one_operand (type,
convert (type, integer_one_node),
arg0);
! case LT_EXPR:
! TREE_SET_CODE (t, NE_EXPR);
break;
default:
break;
}
--- 6851,6886 ----
return omit_one_operand (type,
convert (type, integer_zero_node),
arg0);
case LE_EXPR:
return omit_one_operand (type,
convert (type, integer_one_node),
arg0);
!
! /* The GE_EXPR and LT_EXPR cases are unnecessary because a
! previous optimization converted X >= CST to X > (CST - 1)
! and X < CST to X <= (CST - 1). These two cases are handled
! in the next switch statement. */
!
! default:
break;
+ }
+ else if (TREE_INT_CST_HIGH (arg1) == 0
+ && (TREE_INT_CST_LOW (arg1)
+ == ((unsigned HOST_WIDE_INT) 2 << (width - 1)) - 2)
+ && TREE_UNSIGNED (TREE_TYPE (arg1)))
+ switch (TREE_CODE (t))
+ {
+ case GT_EXPR:
+ code = EQ_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
+ break;
+ case LE_EXPR:
+ code = NE_EXPR;
+ arg1 = const_binop (PLUS_EXPR, arg1, integer_one_node, 0);
+ t = build (code, type, TREE_OPERAND (t, 0), arg1);
+ break;
default:
break;
}
--FL5UXtIhxfXey3p5--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-28 7:10 Glen Nakamura
0 siblings, 0 replies; 16+ messages in thread
From: Glen Nakamura @ 2002-05-28 7:10 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/6822; it has been noted by GNATS.
From: Glen Nakamura <glen@imodulo.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc:
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Date: Tue, 28 May 2002 03:54:54 -1000
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6822
I believe the following patch is the cause of this PR:
2002-05-15 Eric Botcazou <ebotcazou@multimania.com>
* fold-const.c (fold) [LT_EXPR]: Move the transformation of a
comparison against the highest or lowest integer value before
the 'X >= CST to X > (CST - 1)' and 'X < CST to X <= (CST - 1)'
transformation and that of an unsigned comparison against 0
right after.
Previously, unsigned X < 128 would be converted to unsigned X <= 127 and
then optimized to signed X >= 0. After changing the order of the
transformations, the compiler only reduces the expression to X <= 127 ???
The result is the reported ICE. This could very well be a latent bug
in other parts of the compiler, but it seems the change results in missed
opportunities to simplify expressions. I'll post an alternative patch
in my next message...
- Glen Nakamura
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-26 16:46 paolo
0 siblings, 0 replies; 16+ messages in thread
From: paolo @ 2002-05-26 16:46 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, glen, nobody
Synopsis: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
State-Changed-From-To: open->analyzed
State-Changed-By: paolo
State-Changed-When: Sun May 26 13:36:49 2002
State-Changed-Why:
Confirmed as regression wrt 3.1.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6822
^ permalink raw reply [flat|nested] 16+ messages in thread
* optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
@ 2002-05-26 12:26 glen
0 siblings, 0 replies; 16+ messages in thread
From: glen @ 2002-05-26 12:26 UTC (permalink / raw)
To: gcc-gnats
>Number: 6822
>Category: optimization
>Synopsis: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: ice-on-legal-code
>Submitter-Id: net
>Arrival-Date: Sun May 26 12:16:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Glen Nakamura
>Release: gcc version 3.1.1 20020526 (prerelease)
>Organization:
>Environment:
i586-pc-linux-gnu
>Description:
Compiling testcase results in the following ICE:
ice.c: In function `main':
ice.c:12: unrecognizable insn:
(insn:QI 59 24 60 (set (reg:CC 17 flags)
(compare:CC (reg/v:QI 61)
(const_int 128 [0x80]))) -1 (insn_list 24 (nil))
(expr_list:REG_DEAD (reg/v:QI 61)
(nil)))
ice.c:12: Internal compiler error in extract_insn, at recog.c:2132
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
The testcase compiles fine w/ the GCC 3.1 release.
Possible regression on branch w.r.t. GCC 3.1...
>How-To-Repeat:
gcc -O2 ice.i
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="ice.i"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ice.i"
IyAxICJpY2UuYyIKIyAxICI8YnVpbHQtaW4+IgojIDEgIjxjb21tYW5kIGxpbmU+IgojIDEgImlj
ZS5jIgp1bnNpZ25lZCBjaGFyCmZvbyAoKQp7CiAgICByZXR1cm4gMTI4Owp9CgppbnQKbWFpbiAo
KQp7CiAgICB1bnNpZ25lZCBjaGFyIHEgPSBmb28gKCk7CiAgICByZXR1cm4gKHEgPCAweDgwKSA/
IDY0IDogMDsKfQo=
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-06-02 20:06 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-02 13:06 optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132 Glen Nakamura
-- strict thread matches above, loose matches on Subject: below --
2002-06-02 12:36 Richard Henderson
2002-05-30 16:56 rth
2002-05-29 12:16 Richard Henderson
2002-05-29 10:36 Richard Henderson
2002-05-29 9:44 Glen Nakamura
2002-05-29 9:16 Eric Botcazou
2002-05-29 0:46 Glen Nakamura
2002-05-28 18:16 Glen Nakamura
2002-05-28 17:16 Eric Botcazou
2002-05-28 16:36 Eric Botcazou
2002-05-28 11:00 Richard Henderson
2002-05-28 8:16 Glen Nakamura
2002-05-28 7:10 Glen Nakamura
2002-05-26 16:46 paolo
2002-05-26 12:26 glen
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).