[Bug target/12654] [3.3/3.4 regression] Incorrect comparison code generated for Alpha

["tg at swox dot com" <gcc-bugzilla@gcc.gnu.org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12654



------- Additional Comments From tg at swox dot com  2003-10-17 23:03 -------
Subject: Re:  [3.3/3.4 regression] Incorrect comparison code generated for Alpha

"falk dot hueffner at student dot uni-tuebingen dot de" <gcc-bugzilla@gcc.gnu.org> writes:

  No, it isn't, since it is an unsigned value. But passing this value to
  a function taking a signed value is implementation defined.
  
Passing an "unsigned long" value to a function accepting "long"
is perfectly well-defined, as long as no signed overflow happens
in the conversion.  The value used doesn't cause overflow.

  >   The bogus variant is actually slightly better WRT register pressure, so we
  >   might want to retain it for int arguments.
  > 
  > Huh?  Not sure what you are suggesting.  Adding and then comarping
  > to 0 is *wrong* also for int arguments when since the add risks to
  > overflow.
  
  Not if you do a 64-bit add. But it's probably not worth bothering.
  
Yeah, I suppose you can do the trick in SImode by actually doing
the operations in DImode, so to speak.  Alpha is unusual in that
it allowed larger immediate operands for addition (via lda) than
comparison.