------- Additional Comments From jlquinn at optonline dot net 2005-01-16 17:09 ------- Subject: Re: Floating point output is slow
pcarlini at suse dot de wrote: > ------- Additional Comments From pcarlini at suse dot de 2005-01-03 16:41 > ------- > Hi again. Some good news: first, I can confirm that fmttest1.cc does not fail > anymore. Morevoer, on x86-64 lfptest fails with gcc3.3 too, therefore > something > seems wrong in the testcase, not in fpfinal5.patch. While a I dig a little > deeper on these issues (and do complete tests on ia64 too), maybe Jerry, you > can try to fix lfptest: it would be nice to actually run it to success on the > 64-bit machines too... The backtrace is as follows: > (gdb) backtrace > #0 0x0000002a95b2f10b in __printf_fp () from /lib64/tls/libc.so.6 > #1 0x0000002a95b2b416 in vfprintf () from /lib64/tls/libc.so.6 > #2 0x0000002a95b46659 in vsprintf () from /lib64/tls/libc.so.6 > #3 0x0000002a95b31af8 in sprintf () from /lib64/tls/libc.so.6 > #4 0x0000000000401114 in main () at lfptest.cc:58 > > And, if I print fd.d inside gdb just before the segfault: > (gdb) p fd.d > $1 = <invalid float value> > > Are we passing to sprintf a completely crazy third arg?!? Sorry about the delay. I'm really not sure what's wrong with the test program. The backtrace only says that it doesn't like the random long double I'm generating. It appears that x86-64 uses the same long double as x86. The only thing I can think of is that the libs get upset if the top 32 bits that are unused have junk in them. I'm attaching a copy of lfptest that zeros out the top 32 bits so that there are only 80 bits of random numbers and the rest of 128 bits are zero. The other thing you can try is to run the test with dorand=false. This makes it use the loop index as the number to print. It's also a good test to run and can flush out different problems than the random test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
