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: Fri, 13 Jan 2006 22:50:46 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2006-1-13 19:50 UTC, Vadim Zeitlin wrote:
> On Fri, 13 Jan 2006 03:24:07 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> So this test looks like another dead end. Yet two people have observed
> GC> the problem independently, even though I can't reproduce it myself.
> 
>  What exactly have they observed? I don't think users have a habit of
> checking the FPU state directly, so they must have been seen some bug
> which we think is a manifestation of changing FPU default precision, but
> are we really sure about it? Could it be due to something else?

'fenv_lmi.hpp' declares
  void LMI_SO fenv_initialize();
which is called early in WinMain(), before wxEntry is constructed
(it initializes the fpu control word to 0x037f), and
  bool LMI_SO fenv_validate();
which is called just before WinMain() returns; it pops up a messagebox
if the fpu control word does not equal the initial value. They've
observed that messagebox, which tells them that the control word has
become 0x027f.

  0x037f: intel hardware default resulting from FINIT
  0x027f: msvc default

The difference is bit 8, in the "PC" field: the intel default is
extended precision, and the msvc default is double precision. I think
java uses the same default as msvc, while MinGW uses the same default
as intel. These are the two values in most common use on msw, so it
seems unlikely that the value 0x027f would arise randomly.

Testers can reproduce this about one time out of three or four trials.
I haven't been able to reproduce it at all, but I don't use exactly
the same versions of adobe 'acrobat' (and perhaps java) as they do.

The unit tests in 'fenv_lmi_test.cpp' lead me to believe that the
code for loading and storing the control word is correct.

Last night I committed this change

  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.

and we'll see whether that pins down the problem.




reply via email to

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