Fix -- Wide int sign extension in combine.c

Jeffrey A Law
Sun Feb 28 18:15:00 GMT 1999

  In message < >you write:
  > Jeffrey A Law wrote:
  > > 
  > >   In message < >you write:
  > >   > Change to gcc.  When HOST_WIDE_INT is 64 bits.
  > >   > Failure from testcase gcc.c-torture/930506-2.c.
  > > What target?  I haven't seen this test failing on any of the 64bit MIPS
  > > targets I work on regularly.
  > Intel, with HWI set to 64.  You already have the testcase
  > for this one (930506-2.c).
Thanks.  This helps.

Out of curiosity, why is HWI set to 64 for an ia32 target?  While I agree
that it needs to work, setting HWI to 64 when it isn't strictly needed
just slows down the compiler.

In fact, there's only one target I'm aware of that really needs a 64bit HWI.

  >         leal 4294967268(%ebp),%eax  <-----  0xffffffe4 (unopt: this is an '
  > and' involving -29)
  >         movl $____.7-10,%edx
  >         movb $185,(%eax)
  >         movl %ebp,1(%eax)
  >         movb $233,5(%eax)
  >         subl %eax,%edx
  >         movl %edx,6(%eax)
  >         leal 4294967284(%ebp),%eax  <----- 0xfffffff4
  >         movl $____.3-10,%edx
  >         movb $185,(%eax)
  >         movl %ebp,1(%eax)
  >         movb $233,5(%eax)
Certainly suboptimal, not necessarily wrong though.  
  > What I was seeing originally was decimal for 0x1ffffffe4,
That would certainly be wrong :-)

  > work "by accident".)  (Note... other compilers could be generating
  > this, and since this is a compile-only test, you'd never get an
  > error report; the only reason I noticed was that my assembler
  > fell over (weirdly) with the 33 bit value.  In fact, a more
  > robust assembler might simply ignore the problem even with 33
  > significant bits of number.)
Most of the assemblers I work on regularly will scream loudly if we try
to shove a 33bit value into a 32bit field or anything of that nature.  I
got sick and tired of silent operand overflows on targets where it
does matter (consider trying to shove 0xdeadbeef into a 16bit field that
is zero/sign extended before it's actually used by the hardware -- never

  > # Now look at the result.
  > (gdb) p debug_rtx(0x9db220)
  > (plus:SI (reg:SI 6 %ebp)
  >     (const_int 4294967268))
  > $6 = void
  > # Oops, positive.  It got masked down to 32 bits, and since it
  > # will be printed in the assembler as a 64 bit decimal, we've
  > # lost the sign.
Yea.  Ok.  I see it.  Definitely wrong.  This is a 32bit value and therefore
should have been sign extended from bit 32 to HWI.  Call it a brain fart

Hmmm, it's 3am.  I'll comment more tomorrow after I can look at your message
in more detail.


More information about the Gcc-patches mailing list