Sender: nate AT cartsys DOT com
Message-ID: <37C026EA.FBB0F518@cartsys.com>
Date: Sun, 22 Aug 1999 09:35:54 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12pre4 i586)
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: optimization bug in gcc-2.95 (fwd)
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990822110525 DOT 6405K-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> Could someone please see if this behavior of GCC 2.95 (is it new?)
> affects the libm functions nan() and nanf()?  They use a union of an FP
> and an integer variable to generate a NaN.  One symptom of a problem
> would be if ``printf ("%+f", nan());'' prints "-NaN", not "+NaN".
> 
> Of course, to see if a problem exists, you would need to build the v2.03
> alpha with GCC 2.95.

I haven't tried it (I haven't got GCC 2.95 installed yet) but I think
our code is safe.  AFAIK, punning via a union is the correct ANSI way to
access memory as two different types.  What isn't allowed is accessing a
given address through pointers of different types.

It might be a good idea to run this by comp.lang.c, where there are
surely people who know all the picky details.

And yes, it is new.  It was implemented in earlier versions of EGCS, but
one had to use an option (-fstrict-aliasing) to enable it.

<rant>
How could those EGCS/GCC $@#%$s change the default behavior to break so
much extant code, without even making the compiler warn about the broken
code?  They did say it was hard, but IMAO they shouldn't have changed
the default until they got it.
</rant>
-- 

Nate Eldredge
nate AT cartsys DOT com