Date:	Tue, 18 Aug 1998 16:30:03 +0200 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Strange code generated by GCC
In-Reply-To:	<Pine.SUN.3.91.980818141311.12510B-100000@is>
Message-ID:	<Pine.A32.3.91.980818161554.263348B-100000@ieva05.lanet.lv>
MIME-Version:	1.0

On Tue, 18 Aug 1998, Eli Zaretskii wrote:

> Can anybody please explain why does GCC generates such a strange code, as 
> described below?  It is not an idle question: a couple of functions in the 
> new libm (from v2.02) fail because of this.
> 
> Here's the deal.  The program below attempts to generate a float NaN by 
> using the old trick of a union with float and unsigned int members.  
> 0x7fc00000 is the bit pattern for a float NaN.  The problem is that, as 
> the comment says, the program prints 0xffc00000 instead (which is a
> negative NaN).
> 
> I can solve the problem by using memcpy instead of the last assignment in 
> SET_FLOAT_WORD macro, but I'd like to understand why is GCC generate such 
> code, and why optimizations change that.
> 

It is so at least with gcc-2.8.1 under DJGPP. I was unable to test this
with egcs-2.91.53 now as that stuff is installed on a different computer
(and I'm rather far from it). Perhaps I'll do it later.

It is well visible that 0xFFC00000U appears with -O2 (gcc-2.8.1) directly
in assembler source generated by cc1. Both macros are effectively optimized
out.

I think, here are some possibilities:
  - some global bug in gcc. At least on IBM RS6000 (system AIX-4.1.5,
    gcc-2.7.2.1) I'm getting

          SET_FLOAT_WORD: NaNQ, GET_FLOAT_WORD: 7fc00000

    So perhaps this possibility is excluded.

  - some i[34567]86 related bug. Here it would be interesting to check
    on Linux. Unfortunatelly cannot do it now. Maybe later

  - the last variant is DJGPP related bug 

(Of course It's necessary to comment out call to _control87 for both
Linux and AIX)

Andris

- Raw text -