[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Gcc prints NAN for floats that are not NANs



> 
> On Wed, 8 Oct 1997, E.L. Meijer (Eric) wrote:
> 
> > Dunno if I may call myself an expert, but something that would really
> > help in diagnosing the problem, is to try to reduce the code to a small
> > code snippet that produces the problem.  It is hard to comment without
> > seeing any actual code.  The simple fact that code seems to work
> > correctly on one system (FreeBSD) doesn't mean it is necessarily
> > correct, as I discovered myself more than once :(.  Did you try the gcc
> > newsgroups?
> 
> First thanks for replying.
> I could never reproduce the problem on a smaller code. If I put just one
> extra printf() statement the problem disappears and appears elsewhere in
> the code. Here is the code
> 
> #define SCALE           8192    /* scale for fixed point representation */
> #define from_fixed(x)   ((double) (x) / SCALE)
> 
> double x,y;
> 
>    x = (from_fixed(tpi) - utt_scale);
>    x = x / num_obser;
>    x = x + from_fixed((phead->scale));
>    y = ((from_fixed(tpi) - utt_scale)/1.0/ num_obser) + 
>      from_fixed(1.0*phead->scale);
> 
> y produces a NaN and x does not
> int num_obser = 695;
> int phead->scale = 0;
> int utt_scale = 0;
> int tpi = -924593180;
> 
> This is one of the cases that produces a NAN for y. Once y is NAN no
> matter what values tpi, and num_obser are it becomes a NaN after
> performing the calculation. 
> 
> I understand what you mean when you say the fact that it worked on FreeBsd
> and Solaris doesn't mean its correct. But I am suprised that if I use the
> linear method as in 'x', it does not occur. 
> 
> Lastly, I could not duplicate it on a smaller code. I wonder how are the
> NaN bits set on the Intel CPU. By the way is well documented that the
> Alpha chip has this problem for gcc. 

Thinking about it a little longer, I start to get the feeling that the
problem may be totally outside the code you showed.  If there is some
kind of memory corruption going on, parts of y can get overwritten by
totally unrelated code.  Maybe you can check this tracing the program
in gdb.  Set a watchpoint on y and determine when exactly it gets the
NaN value.  It could also be a good idea to link the program with the
electric fence malloc libraries (available as a debian package) to see
if you can trap any illegal reads or writes.

Eric Meijer

-- 
 E.L. Meijer (tgakem@chem.tue.nl)          | tel. office +31 40 2472189
 Eindhoven Univ. of Technology             | tel. lab.   +31 40 2475032
 Lab. for Catalysis and Inorg. Chem. (TAK) | tel. fax    +31 40 2455054


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: