Re: Workaround for Sun V5.0 compiler

[Michael Chamberlain <michael at chamberlain dot net dot au>]

On Fri, Aug 27, 1999 at 11:35:43PM -0600, Jeffrey A Law wrote:
> There's been numerous reports of bootstrap comparison failures when building
> gcc-2.95[.1] with the Sun V5.0 compilers.  Through the efforts of Patrick Chan
> we have been able to isolate a bug in the Sun V5.0 compiler.
> 
> For the interested parties, here's the testcase the Sun compilers mis-compile:
> 
> foo(long x)
> {
>   if ( -x >= 0 )
>     printf("%ld is >= 0\n", -x);
>   else
>     printf("%ld is < 0\n", -x);
> }
>  
> main()
> {
>   foo (0x80000000);
> }

Assuming that the compiler in question uses 32 bit longs, then I think the
above code invokes undefined behaviour by overflowing the long when
negating it. The Sun compiler may guarantee something more than what the
standard requires, but unless it does so I don't think the result of the
above program (whatever that result is) could be considered a bug from the
point of view of ISO C.

>   	  if (const_arg1 != 0 && GET_CODE (const_arg1) == CONST_INT
>   	      && INTVAL (const_arg1) < 0
> ! 	      /* This used to test
> ! 
> ! 	         - INTVAL (const_arg1) >= 0
> ! 
> ! 		 But The Sun V5.0 compilers mis-compiled that test.  So
> ! 		 instead we test for the problematic value in a more direct
> ! 		 manner and hope the Sun compilers get it correct.  */
> ! 	      && INTVAL (const_arg1) != (1 << (HOST_BITS_PER_WIDE_INT - 1))
>   	      && GET_CODE (folded_arg1) == REG)
>   	    {
>   	      rtx new_const = GEN_INT (- INTVAL (const_arg1));

I think the above code may also invoke undefined behaviour, by shifting
into the sign bit. I believe an expression that achieves the same effect,
but does not invoke undefined behaviour, would be:

              && (INTVAL (const_arg1)
                  >= - (((HOST_WIDE_INT) 1)
                        << (HOST_BITS_PER_WIDE_INT - 2) * 2 + 1)

where the expression after the unary minus is (I hope) the same as
HOST_WIDE_INT_MAX (ie, INT_MAX, LONG_MAX, etc)- perhaps it would be
worthwhile including it as a #define somewhere instead of representing it
directly.

Michael.