[Bug c/55378] New: Inconsistant double 387 computation when using osthread

[Bug c/55378] New: Inconsistant double 387 computation when using osthread

[philippe.coustaux at gmail dot com]

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: unassigned@gcc.gnu.org
        ReportedBy: philippe.coustaux@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.0000000000000000P-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

[Bug c/55378] Inconsistant double 387 computation when using osthread

[philippe.coustaux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378

philippe.coustaux at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |Mingw, cygwin
               Host|                            |Windows

--- Comment #1 from philippe.coustaux at gmail dot com 2012-11-18 14:16:40 UTC ---
This my interpretation:

As the values in 'pond' are the same, the loop line 158 will produce 5! (120)
the same value in s1

So the problem came from line 165 or 167 under windows threads.

[Bug target/55378] Inconsistant double 387 computation when using osthread under windows

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|Mingw, cygwin               |i?86-*-mingw*
                   |                            |i?86-*-cygwin-*
          Component|c                           |target
               Host|Windows                     |
           Severity|major                       |normal

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-11-19 01:55:29 UTC ---
The difference is 1ulp correct?  Maybe there is different rounding modes are
selected for the main thread and the spawned threads.  Can you see which mode
of i387 is used for each?  Maybe the spawned threads are using 80bits while the
main thread is using 64bits.

[Bug target/55378] Inconsistant double 387 computation when using osthread under windows

[philippe.coustaux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378

--- Comment #3 from philippe.coustaux at gmail dot com 2012-11-19 05:00:07 UTC ---
Hi,

The difference is not always 1ulp. If you look at 'RUN-LOG-30.txt' output file
you can see that its 3ulp. If you ran the binary with a value of 100 the
difference grows to 5ulp.

tcc generated code don't present the bug even with very high values of the
parameter.

Regarding my tests, the result closest to the 'right' value is always given by
the main thread. When in a spawned thread, result loose accuracy.

Regarding of using 64bits or 80bits I dont't know. How can I check that ? How
can I change the rounding mode ?

[Bug target/55378] Inconsistant double 387 computation when using osthread under windows

[philippe.coustaux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378

--- Comment #4 from philippe.coustaux at gmail dot com 2012-11-19 05:19:07 UTC ---
Ok, I have found for the rouding mode.

[Bug target/55378] Inconsistant double 387 computation when using osthread under windows

[philippe.coustaux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55378

--- Comment #5 from philippe.coustaux at gmail dot com 2012-11-19 06:05:17 UTC ---
I have added a #include <fenv.h>
and calls to fegetround
The return value is 0 in thread or in main.

Reproducible with cygwin and mingw