Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132

[Richard Henderson <rth at redhat dot com>]

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~