http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378
Bug #: 55378
Summary: Inconsistant double 387 computation when using
osthread
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: philippe.coust...@gmail.com
Created attachment 28723
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28723
Full testcase for win32 and cygwin
This program compute a bayes propability and accept one parameter with is used
to set up initial weights.
The proc ComputeBayes_p is called directly once from the main()
and once called within an os thread.
The same code is executed in both context.
The expected behavior is that the result of computation be the same in both
context.
The inconsistancy appears depending of the parameter, and of the optimisation
level
Some low weights bits vary.
for low values of the parameter (15) the problem doesn't occurs with low
optimization.
for higher values (30) the problem appears even with -O0 and -g optimization
level
There is 2 subdirectory.
one named cyg for unix compilation, one named win for windows.
The "build" compile the program with different optimisation levels
the "test" script run the compiled binaries
the "run-test" use the test script with 2 parameter value.
The output of the program provide the diag:
>> Global result <<<
./U3 15 >> ** Thread bug.**.
= Details ==
Difference Dec/Hex (Without / With):
5.421010862427522e-20 / 0X1.P-64
The line with the diag is a copy of the arg line and using the conventions used
by the build script, indicate the optimization level. (hehe -O3)
the last line is the delta between computation without thread and the
computation with thread
I have conducted the tests on winxp and seven on two intel processors, amd
seems to have same behavior
It's reproducible with mingw and with cygwin.
The problem doesn't appears with sse math
and tests on a true debian linux doesn't exibit the problem.
To reproduce the problem, use a windows console or a cygwin terminal
Go in the adequate directory
run the build script to compile the test,
launch the run-test script to produce the RUN-LOG-?? files that trace the
problem.
The problem seems similar to:
http://sourceforge.net/tracker/?func=detail&atid=102435&aid=3409958&group_id=2435
