This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin gcc: Different numerical results in thread vs in main()


Richard Stanton wrote:

> Main:        t/1+t =    0.0005609048868329022342546
> Thread 0: t/1+t =    0.0005609048868329021258344
> Thread 1: t/1+t =    0.0005609048868329021258344
> Thread 2: t/1+t =    0.0005609048868329021258344
> Thread 3: t/1+t =    0.0005609048868329021258344

The difference is because the 387 in the main thread has its rounding
mode set to extended precision, whereas in the threads it's set to
double precision.  Cygwin sets the control word to extended precision in
its crt startup code; apparently the Windows default for new threads is
double precision and it's not explicitly set by Cygwin in
pthread::thread_init_wrapper.  Arguably it should set it there too for
consistency.

But the results are the same to 15 significant digits which is all you
can expect out of an IEEE double, so this is technically correct.  The
excess precision issue with 387 math is well known, see gcc PR323.

If your architecture supports sse2 then you can use that instead of the
387 unit with -fpmath=sse2 (in conjunction with the relevant -march= of
course, or -msse2).  The sse2 unit always does double calculations in
double precision, there is no extended mode, so this is not an issue.

You could also set the 387 control word yourself at your thread's start
function.  

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]