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:
[EMAIL PROTECTED] */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.
[EMAIL PROTECTED] */packages/dos 78 :
--
Summary: NaN or correct result after divrp with 3 FPU registers
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sraa at kse dot nl
GCC build triplet: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure -
-prefix
GCC host triplet: GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
GCC target triplet: Solaris 10 GA x86 SunOs 5.10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24743
