From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-19180-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 1850 invoked by alias); 29 May 2002 17:36:14 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 1816 invoked by uid 71); 29 May 2002 17:36:08 -0000
Date: Wed, 29 May 2002 12:16:00 -0000
Message-ID: <20020529173608.1811.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Richard Henderson <rth@redhat.com>
Subject: Re: optimization/6822: GCC 3.1.1 - Internal compiler error in extract_insn, at recog.c:2132
Reply-To: Richard Henderson <rth@redhat.com>
X-SW-Source: 2002-05/txt/msg00963.txt.bz2
List-Id: <gcc-prs.sourceware.org>

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~