Re: [bugs] a gcc sign bug?

[Jan Hubicka <jh at suse dot cz>]

> On Fri, Jun 01, 2001 at 02:08:19PM +0200, Jan Hubicka wrote:
> > 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.
> 
> CONST_INT is supposed to be properly sign-extended on
> the host, which means we got overflow there as well.
We are probably out of sync
what I am shooting for is DImode x=x+0xffffffff80000000 expression.
It gets matches, as the constant is sign extension of 0x80000000, so
x86_64_sign_extended value returns 1.

Then the output template sees negative value and decides to "bautify the
code" by using sub, instead of add.
On 32bit HOST_WIDE_INT we get overflow, but 64bit HOST_WIDE_INT we get
constant 0x100000000, that is out of range. We output the instruction and
it gets rejected by assembler, as nonexistent. 

So the problem has nothing to do with HIST_WIDE_INT and CONST_INT versus
CONST_DOUBLE representation, as long as we assume HOST_WIDE_INT >= 32bit.

It is purely x86_64 restriction for this single value. Similar test is perofrmed
on same line for -128, that gets converted to 127 and requires 4 byte immediate.
What I am ruling out is exactly the same, just for 32bit immediates instead of
8bit.

      /* Make things pretty and `subl $4,%eax' rather than `addl $-4, %eax'.
	 Exceptions: -128 encodes smaller than 128, so swap sign and op.  */
      if (GET_CODE (operands[2]) == CONST_INT
          && (INTVAL (operands[2]) == 128
	      || (INTVAL (operands[2]) < 0
		  && INTVAL (operands[2]) != -128)))

Honza