This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [bugs] a gcc sign bug?
- To: Richard Henderson <rth at redhat dot com>, Jan Hubicka <jh at suse dot cz>, Frank van der Linden <fvdl at wasabisystems dot com>, gcc-patches at gcc dot gnu dot org, bugs at x86-64 dot org
- Subject: Re: [bugs] a gcc sign bug?
- From: Jan Hubicka <jh at suse dot cz>
- Date: Fri, 1 Jun 2001 14:08:19 +0200
- References: <20010530231747.A27294@vaasje.org> <20010531125351.D926@atrey.karlin.mff.cuni.cz> <20010531141336.C17766@redhat.com>
> On Thu, May 31, 2001 at 12:53:51PM +0200, Jan Hubicka wrote:
> > > gcc will generate:
> > >
> > > itsabug:
> > > .LFB1:
> > > pushq %rbp
> > > .LCFI0:
> > > movq %rsp, %rbp
> > > .LCFI1:
> > > movq kva_start(%rip), %rsi
> > > subq $2147483648, %rsi
> > > ^^^^^^^^^^^
> > > movl $.LC0, %edi
> > > movb $0, %al
> > > call printf
> > > popq %rbp
> > > .LCFI2:
> > > ret
> > the patch fixes it by converting subq to addq, in same way as we keep -128
> > as addq.
> >
> > Thu May 31 12:52:38 CEST 2001 Jan Hubicka <jh@suse.cz>
> > + /* Avoid overflows. */
> > + && ((INTVAL (operands[2]) & ((1 << 31) - 1)))
>
> I don't like this especially. I'd rather we used INT_MIN
> and such, but this is a HOST_WIDE_INT.
>
> Would you create HOST_WIDE_INT_MIN and HOST_WIDE_INT_MAX
> defines in hwint.h and use that instead?
This is not overflow on host side, as HOST_WIDE_INT is 64bit,
it is overflow on target side, as x86_64 limit immediates to
32bit sign extended expressions.
Honza
>
>
> r~