> > 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 ([EMAIL PROTECTED]) | 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
