Hello, (OS, machine and compiler info in bottom of this message). In certain sources I get a problem that a calculation with floats gives a NaN. It occurs when parens are used for the division (they are not neccessary, but it is not wrong). But when two same instructions are placed after each other there is no problem with the second one. Also when other lines are between the firs with parens and the second instruction with parens, there is no problem. The problem is unfortunately not reproducable with a short program. Still I can't reproduce the problem by means of a short program. I let three system run calculations for day's. The disassembly shows the same instructions, and here no problems at all. So I can not deliver a small program that reproduces the problem.... but sometimes under some conditions a NaN is the result of a calculation with normal values (we don't want high precision, and numbers are not above 5000.000) The software is also not multithreaded... I also tested with schedctl_start and stop if it has something to do with context swithing. But results where the same. Short piece of disassemby where is often goes wrong: gewenst1 = uitspit->gewenst[dosering] * batch / 100.0; <-- Works always 20e2: 8b 15 00 00 00 00 mov 0x0,%edx 20e8: 8b 45 08 mov 0x8(%ebp),%eax 20eb: d9 84 82 6c 07 00 00 flds 0x76c(%edx,%eax,4) 20f2: d8 4d f0 fmuls 0xfffffff0(%ebp) 20f5: d9 05 78 04 00 00 flds 0x478 20fb: de f9 fdivrp %st,%st(1) 20fd: d9 9d d4 f5 ff ff fstps 0xfffff5d4(%ebp) gewenst2 = uitspit->gewenst[dosering] * (batch / 100.0); <-- Works NOT always, sometimes NaN!!! 2103: 8b 15 00 00 00 00 mov 0x0,%edx 2109: 8b 45 08 mov 0x8(%ebp),%eax 210c: d9 84 82 6c 07 00 00 flds 0x76c(%edx,%eax,4) 2113: d9 45 f0 flds 0xfffffff0(%ebp) 2116: dd 05 80 04 00 00 fldl 0x480 <----- opcode not in Intel manual?! 211c: de f9 fdivrp %st,%st(1) <--- opcode DE F9 belongs to fdiv 211e: de c9 fmulp %st,%st(1) 2120: d9 9d d0 f5 ff ff fstps 0xfffff5d0(%ebp) gewenst3 = uitspit->gewenst[dosering] * (batch / 100.0); <-- Works always 2126: 8b 15 00 00 00 00 mov 0x0,%edx 212c: 8b 45 08 mov 0x8(%ebp),%eax 212f: d9 84 82 6c 07 00 00 flds 0x76c(%edx,%eax,4) 2136: d9 45 f0 flds 0xfffffff0(%ebp) 2139: dd 05 80 04 00 00 fldl 0x480 213f: de f9 fdivrp %st,%st(1) 2141: de c9 fmulp %st,%st(1) 2143: d9 9d cc f5 ff ff fstps 0xfffff5cc(%ebp) So I can desribe the problem as follows: The result of "fdivrp %st, %st1" (or fdiv) goes wrong when the FPU-stack is used (more than normal): as long as only ST(0) and ST(1) are used the results are o.k., but when ST(2) is used it goes wrong. In this calculation X = A * (B / 100.0), all 3 variables are pushed on the FPU-stack. The result is "NaN". But only the first time that this construction is used in this source! ....... Is gcc producing wrong assemby? Since fdivrp is fdiv when you look at the opcode. Also the opcode of fldl is not in the Intel manual... Or is the disassember (gobjdump) wrong? When the 100.0 is used via a float, the code is different and there is no fldl used but only flds. We don't want to rewrite our complete application of roughly 300.000 lines. So it would be nice if someone knows where the problem is. Sorry if bug report not quite what's expected. But after three weeks working on this problem this is the best I can do, and hope that someone can say something wise about this. Thanks in advance. Best Regards, Stefan Raaijmakers We use Advantech hardware, with Intel Pentium 4 2.8 GHz Celeron with Solaris 10 x86 (32bit) installed. gcc -v save-temps: mira@promas */packages/dos 77 : make Checking dependencies, please wait... mdept - Dependency DosUitspit.c newer than ./DosUitspit.o `DosDiv.o' is up to date. `DosLib.o' is up to date. cc -g -Wcast-align -v save-temps -DNO_ANSI -I../../include -I/usr/pm_tools/inclu de -c DosUitspit.c cc: save-temps: No such file or directory Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix =/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --w ithout-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) /usr/sfw/libexec/gcc/i386-pc-solaris2.10/3.4.3/cc1 -quiet -v -I../../include -I /usr/pm_tools/include -DNO_ANSI DosUitspit.c -quiet -dumpbase DosUitspit.c -auxb ase DosUitspit -g -Wcast-align -version -o /var/tmp//cctIUOWh.s ignoring nonexistent directory "/usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/../.. /../../i386-pc-solaris2.10/include" #include "..." search starts here: #include <...> search starts here: ../../include /usr/pm_tools/include /usr/local/include /usr/sfw/include /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/include /usr/include End of search list. GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) (i386-pc-solaris2.10) compiled by GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath). GGC heuristics: --param ggc-min-expand=46 --param ggc-min-heapsize=31687 /usr/sfw/bin/gas --traditional-format -V -Qy -s -o DosUitspit.o /var/tmp//cctIU OWh.s GNU assembler version 2.15 (i386-pc-solaris2.10) using BFD version 2.15 `DosVid.o' is up to date. mira@promas */packages/dos 78 :
Do you have a small source code which exposes the issue here? (Note I saw "So I can not deliver a small program that reproduces the problem.... " but we really cannot do anything about it if there is not a testcase) Another thing is that you are using a GCC provided by Sun/Codesourcery and we (FSF) really don't support that version of GCC. You really should had filed a bug report to them first.
Subject: RE: NaN or correct result after divrp with 3 FPU registers Hello, That's the big problem. I'm trying for three weeks to get the problem expose itself in a small program. But I can't get it wrong on purpose. Otherwise I would have filled in a bug report 3 weeks ago. So it's a combination of the application with all it's use of memory and the instructions. It manifests regularly but not constant at our customer. It's a large application and communicating with PLC's. Even for me is hard to simulate the proces of the factory at our office. When I'm "lucky" I get the problem once a day. A lot of quesions: - Is there another way that someone with knowledge of gcc (development) can help me? Maybe someone in The Netherlands. - Or can you recommend someone at Sun? - Why isn't this version supported? - Is it better for me to build a new version of gcc myself? - When I build a new version on one system, is it possible to copy only the gcc executable to other systems, or do I need more, or even build again on all systems needing the new version (I don't expect this, but I ask to be sure). - When I send a .i or .s file of the source where it goes wrong, is there nothing you can say about it. I really have a very big problem since a few systems are waiting on a solution. Anyhow, thanks for the fast reply, and I hope that you can help me or answer my questions! Best regards, Stefan Raaijmakers. -----Original Message----- From: pinskia at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org] Sent: dinsdag 8 november 2005 22:23 To: sraa@kse.nl Subject: [Bug target/24743] NaN or correct result after divrp with 3 FPU registers ------- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 21:23 ------- Do you have a small source code which exposes the issue here? (Note I saw "So I can not deliver a small program that reproduces the problem.... " but we really cannot do anything about it if there is not a testcase) Another thing is that you are using a GCC provided by Sun/Codesourcery and we (FSF) really don't support that version of GCC. You really should had filed a bug report to them first. -- pinskia at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24743 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. ____________________________ Head Office: KSE Group Rondweg 27 NL-5531 AJ Bladel Phone: +31 (0)497 383818 Fax: +31 (0)497 383840 Visit our website at: www.kse.nl **************************************************************************** If you as intended recipient have received this e-mail incorrectly, please notify the sender (by e-mail) immediately. This e-mail is confidential and may be legally privileged. KSE Group does not guarantee that the information sent and/or received by or with this e-mail is correct and does not accept any liability for damages related thereto. KSE Group also does not accept any liability in case of the presence of viruses. ****************************************************************************
We found out that the stackpointer was unbalanced at a given point. Via a small program in assembly wich reads the stackpointer that I placed at suspicious points in the code I found a function that didn't restore the stackpointer correctly. This function was of type float and returned a float but this result was not assigned to any variable... So this has to be it. I know this for sure on monday since the production has stopped now and I cannot test it. Example of the false code: partijlocmut_kg(geleverd1); /* returns a float ..... */ Instead of: geleverd1 = partijlocmut_kg(geleverd1); So a Sun hadn't this problem because the stack is managed differently and the floating point calculations are done by the software instead of a FPU with using of the stack registers. Or has something smart or by coincidence to return the float to a register anyhow. I think it returned the value to the parameter with which the function was called. Otherwise the software wouldn't have worked. If our software was written, in ANSI-C, with correct prototyping of functions, the compiler would have been able to signal the error. Unfortunalely it isn't. But now we know how to seatch or what we have to do..... The cause for my problems was not a buggy OS or compiler but just bad written code.