Date: Sat, 20 May 2000 16:38:13 -0400 (EDT)
Message-Id: <200005202038.QAA25381@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
CC: djgpp-workers AT delorie DOT com
In-reply-to: <200005181522.RAA01200@cerbere.u-strasbg.fr> (message from Pierre
	Muller on Thu, 18 May 2000 17:04:04 +0200)
Subject: Re: Simple C program showing FPU problem !
References: <200005181208 DOT OAA08131 AT lws256 DOT lu DOT erisoft DOT se> <200005181522 DOT RAA01200 AT cerbere DOT u-strasbg DOT fr>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Thu, 18 May 2000 17:04:04 +0200
> From: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
> 
>  I send the source code of a very simple C program that should this bug
> 
> The source follows Eli's restriction's that the FPU must be reset 
> inside the signal handler but when run on a Pentium II 200 MHz (non MMX)
> under Win95 I still get a nonzero overridecount meaning that a
> second exception is sometimes raised inside the signal handler itself.

I can confirm these symptoms: on Windows 98, I get about 0.01% of
signals inside the signal handler.

> This behavior is documented in the Intel docs, that say the 
> the FPU status word should be reset before resetting the IO port.

Please tell where exactly do you see this in the Intel docs, I'm not
sure I understand the issue from this single sentence.

Right now, it looks like the signals you get inside the signal handler
come from outside the program.  I'm guessing that they happen because
some other piece of Windows software that works in parallel to your
program issues FP instructions, and your program gets Int 75h that it
didn't deserve.

Note that the low-order byte of the FPU status word is zero when these
extra signals are delivered.  This alone should tell that those are
fake signals, not originating from your program that divides by zero.

I changed your signal handler as shown below, and the extra signals
seem to be effectively ignored, they do not cause any abnormal
behavior outside the handler.  Perhaps you could do something similar
in your Pascal support routines.  For example, you could ignore those
signals.

    void
    fpesig (i)
      int i;
      {
	void (*oldFPE)(int) = signal (SIGFPE, SIG_IGN);
	fpustate=_clear87();
	if ((fpustate & 0xff) != 0)
	  level++;
	signal (SIGFPE, oldFPE);
	longjmp(t,1);
      }

The two lines which set SIGFPE to SIG_IGN are just due to paranoia:
the trick with ignoring signals whose exception bits are all reset
works even if I remove those two lines.