[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Alien msvc rtl dll messing with the fpu?
From: |
Greg Chicares |
Subject: |
Re: [lmi] Alien msvc rtl dll messing with the fpu? |
Date: |
Tue, 07 Feb 2006 01:47:46 +0000 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
On 2006-1-13 22:50 UTC, Greg Chicares wrote:
>
> 20060113T0434Z <address@hidden> [1205]
>
> system_command.cpp
> Try to localize a reported problem. Pollution of the floating-point
> environment is detected on exit, sporadically, after printing. Check
> the control word immediately after printing, resetting it and printing
> a warning if a problem is found.
This problem has reared its head again. An external end user reported
it today. And now we have a testcase that doesn't involve printing at
all, and is consistently reproducible--though only on certain machines,
and not on mine.
With the changes committed 20060206T1816Z, the floating-point control
word is tested every hundred msec, and a diagnostic saying that it has
been changed from 0x037f to 0x027f appears when the msw file-open dialog
is first used. Despite our earlier reasoning that this should not cause
the problem, the symptom is so eerily reminiscent of this old discussion
http://community.borland.com/article/0,1410,17627,00.html
that I've just committed another change that strives to pre-load all
system dlls that the application uses, directly or indirectly. Compare
the list of dlls added to 'main_wx.cpp' against the result of
/MinGW-20050120/bin/objdump -p ./lmi_wx_shared.exe |grep 'DLL Name'
applied recursively--i.e., here, that command yields
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll
DLL Name: USER32.dll
DLL Name: wxmsw254d_gcc_custom.dll
DLL Name: wx_new.dll
DLL Name: liblmi.dll
but applying it to 'wxmsw254d_gcc_custom.dll' yields other dlls.
As the article cited above points out, this problem can cause
1.189731495357232E+4932L / 1.0L
to evaluate to zero, and borland's rtl performs that calculation when
extracting values of type double from an iostream. This often resulted
in a "Floating Point: Overflow" message, then abnormal termination
with borland tools. Of course, we don't use borland's rtl with gcc,
but this example shows that switching from a 53-bit to a 64-bit
significand can have worse consequences than making calculations
slightly less precise.
- Re: [lmi] Alien msvc rtl dll messing with the fpu?,
Greg Chicares <=
Re: [lmi] Alien msvc rtl dll messing with the fpu?, Greg Chicares, 2006/02/14