------- Comment #19 from dominiq at lps dot ens dot fr 2010-04-14 10:25 ------- > Can you track where the NaN comes from and if it is indeed unexpected > even with -ffast-math -ffinite-math-only?
First '-ffast-math' implies '-funsafe-math-optimizations -ffinite-math-only'. To reach > This is because Re is a NaN because debm is a NaN. I tried to print deve and > devs, but this make the code to work. I have added an IF in S00061 that print some results if i1 is less than 1 or greater than 20 (i.e., a poor man's bound check). With that I see that Re is a NaN when the code crashes an nothing when the code works (e.g., after reverting revision 158105). The bad news is that the code "works" if I try to print the variables deve or devs (Re=(deve+devs)/2.0) and I did not find a way to overcome it. From my experience, a change of behavior when printing something is a good clue that there is some memory mismanagement (usually due to using arrays outside their bounds). Note also that S00061 is compiled the same way before of after r158105 (I have even checked it before opening this pr). I have no knowledge at all of doduc (see http://www.spec.org/cpu92/DESCR.015 ). The first time I heard anything about it (~20 years ago) was because it was considered at that time as a "compiler breaker". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
