This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]