Re: Win32 CTRL-C handling (Was: interrupt handing and the GUI (bug #37672))

[John W. Eaton]

On 11/19/2013 11:56 AM, Michael Goffioul wrote:
> On Tue, Nov 19, 2013 at 1:10 AM, John W. Eaton <address@hidden
>
>     Your change works for me with MinGW.
>
>
> I forgot to mention one thing about that patch. Most of it is not MSVC
> specific, but there's one bit that is MSVC-specific: I need to call
> _fpreset before doing the longjmp. The reason is I noticed weird
> floating-point results after interrupting some LAPACK routine
> (typically, I used "inv" for testing interrupt); the first
> floating-point comparison was always invalid (like "0 == 0" returning
> 0). I tracked down the issue until an assembly-call FLD that was loading
> an valid value on the FPU stack, although the memory it was loaded from
> appeared to contain the correct bytes. I figured it could be due to the
> sudden interruption of the LAPACK routine, leaving the FPU in some
> undefined state; hence I added the _fpreset call.
>
> I don't know whether the problem also occurs in MinGW, but if it does, I
> suppose there's a MinGW-equivalent to _fpreset.

I don't know whether the problem happens.  The MinGW float.h says
this:

  /*
     MSVCRT.dll _fpreset initializes the control register to 0x27f,
     the status register to zero and the tag word to 0FFFFh.
     This differs from asm instruction finit/fninit which set control
     word to 0x37f (64 bit mantissa precison rather than 53 bit).
     By default, the mingw version of _fpreset sets fp control as
     per fninit. To use the MSVCRT.dll _fpreset, include CRT_fp8.o when
     building your application.
  */
  void __cdecl __MINGW_NOTHROW _fpreset (void);
  void __cdecl __MINGW_NOTHROW fpreset (void);

Using it is subject to getting the right version of float.h for the
declaration.  See my comment on the bug tracker about that problem
here:

  https://savannah.gnu.org/bugs/?40607#comment20

jwe