[Bug c/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 15:22 -------
Subject: Re:  [3.3/3.4 regression] Incorrect comparison code generated for Alpha

"falk at debian dot org" <gcc-bugzilla@gcc.gnu.org> writes:

  (the posted test case is technically invalid).
  
The test case is perfectly valid.
The test is the function foo.

In order to drive that portably, a somewhat odd expression is
needed.  Are you saying the ~0L is "technically invalid", since
it contains an overflow of signed data?  Is that relevant for the
test case's validity?  Please take a look at gcc's testsuite for
one million of examples where driver programs for constants that
ate "technically invalid".

I wrote the test in the c-torture style, intended for its execute
category, since I really don't want this sort of bugs to come
back.  We had problems like this back in the gcc 1.x days, and I
am disapppointed we now again have somebody with poor two's
complement understanding checking in code in gcc.

  gcc 2.95 got it right, 3.2 not. Probably target dependent, but I don't have 
  anything else to test currently.
  
Poking around the gcc sources (alpha.c alpha_emit_conditional_branch)
showns that the bogus code has been there for a while.

  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.