lmi
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]