Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!usc!elroy.jpl.nasa.gov!decwrl!sgi!davea@quasar.wpd.sgi.com
From: davea@quasar.wpd.sgi.com (David B.Anderson)
Newsgroups: comp.sys.sgi
Subject: Re: HUGE
Summary: ccom bug. narrowing double constant to float constant
Message-ID: <81791@sgi.sgi.com>
Date: 18 Jan 91 21:38:47 GMT
References: <72495@bu.edu.bu.edu> <1991Jan17.201925.2264@odin.corp.sgi.com> <61848@brunix.UUCP>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 54

In article <61848@brunix.UUCP>, sgf@cs.brown.edu (Sam Fulcomer) writes:
> In article <1991Jan17.201925.2264@odin.corp.sgi.com> bruceh@sgi.com (Bruce R. Holloway) writes:
> >In article <72495@bu.edu.bu.edu> tjh@bu-pub.bu.edu (Tim Hall) writes:
> >>
> >The problem isn't that HUGE needs to be attenuated.  It's that the MIPS
> >C compiler didn't respect the cast to float in your constant definition.
> 
> ok, but why doesn't
> 	if( a == (float)NOVALUE)
> work?

bruceh is correct.

Since this has become a hot issue I'll elaborate:
	((float) NOVALUE)
should narrow the constant (when NOVALUE is a double constant) to a float.

However, in 3.3, the constant did not get narrowed. 

Fortunately, this is rarely a problem.  Unfortunately, when it bites
someone it is confusing to look at the code because it is the _constant_
which was not narrowed (the generated code is ok, the constant is bad).  
The .s output of Mr. Hall's compile would be in part (cc -g):

compiled with 3.3 cc:
        li.s    $f4, 3.4028234699999997e+35
        s.s     $f4, 28($sp)
        cvt.d.s $f6, $f4
        li.d    $f8, 3.4028234699999997e+35
        c.eq.d  $f6, $f8
        bc1f    $32

One gets the un-narrowed NOVALUE $6 rather than the double-precision
version of the narrowed one.

Now look at the same compiled under 4.0 cc:

        li.s    $f4, 3.4028234346940236e+35
        s.s     $f4, 28($sp)
        cvt.d.s $f6, $f4
        li.d    $f8, 3.4028234346940236e+35
        c.eq.d  $f6, $f8
        bc1f    $32

Same code, but the constant is  now correct.

In general, narrowing *does* happen correctly in 3.3 C. However in
the above case (constant double narrowed to float) it does not.

This is fixed in the next major release (4.0).

Hope this elaboration helps a little.
[ David B. Anderson  Silicon Graphics  (415)335-1548  davea@sgi.com ]
[``What can go wrong?''                           --Calvin to Hobbes]