From: buers AT gmx DOT de (Dieter Buerssner)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: SIGFPE
Date: 13 Feb 2000 13:00:10 GMT
Lines: 88
Message-ID: <8869sp$rfgt$1@fu-berlin.de>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000213095538 DOT 29873N-100000 AT is>
NNTP-Posting-Host: dialup-212.162.12.38.frankfurt1.mik.net (212.162.12.38)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: fu-berlin.de 950446810 900637 212.162.12.38 (16 [17104])
X-Posting-Agent: Hamster/1.3.8.0
User-Agent: Xnews/2.11.08
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

djgpp AT delorie DOT com (Eli Zaretskii) wrote in 
<Pine DOT SUN DOT 3 DOT 91 DOT 1000213095538 DOT 29873N-100000 AT is>:

>
>On 11 Feb 2000, Dieter Buerssner wrote:
>
>> >     if (c != 0.0)
>> >     {
>> >          temp  = 1.0 / c;
>> 
>> The last statement may overflow (to Infinity), and thus may cause
>> a floating point exception, i.e when c is a subnormal/denormal 
>> number.
>
>Not in DJGPP v2.02 and later (but since the original poster seems to
>use v2.01, it's possible in this case).  In latest versions of DJGPP,
>Infinity never causes an exception, it just results in all subsequent
>results being Inf, NaN, or zero.

... or one (tanh(Infinity) = 1.0), or pi/2 ... .

Yes, you are correct, In newer versions of djgpp all math
exceptions are masked. I think this is even suggested in the
IEEE floating point standard. But of course, it can be of
advantage to allow some math exceptions, especially during
development phase, to catch actual bugs. The OP did not
indicate, that he has set the exception mask. So you are
probably correct that he uses and older version of djgpp.

I am agreeing with your suggestion of upgrading djgpp. And this
may cure the problem of the OP. But it is also possible,
that it will actually hide the bug, at the place where it is
occuring.

To the Peter Restall. I am assuming at least a, b, c, temp, u_end and 
v_end are floating point variables. In your code snippet

	if (c != 0.0)
	{
		temp  = 1.0 / c;
		u_end = (a * temp) * txt_buf->f_width;
		v_end = (b * temp) * txt_buf->f_height;
	}
	else
	{
		u_end = 0;
		v_end = 0;
	}

you are trading (in the if clause) one division and two
multiplications against two divisions (which probably would
execute a little slower). 
You may want to try the method with the two divisions -
u_end = (a / c) * txt_buf->f_width; ... 
Your problem might go away then, if, whenever c is denormal,
a and b are also small. But, doing arithmetics with denormals,
will loose precision. To cure this, it might be possible,
to prescale a, b, c. (Find the maximum of fabs(a), fabs(b) and
fabs(c), and divide a, b, c by this maximum). 

>What exactly do you mean by ``subnormal'', btw?  I know about
>denormals and unnormals (the latter can only happen if the program has
>a bug), but I don't think I've ever heard of subnormals.

I meant it as a synonym to denormal. I thought subnormal was more 
descriptive (below normal). I only used subnormal, because
there was some confusion in a private conversation, where I
used denormal, and it was understood as unnormal.

>> execute it with fsdb. Set a breakpoint at the start of
>> this offending function, and single step through the function,
>> while looking at the NPX pane. This should give you some hints.
>
>GDB also supports FP registers, so this can be done with GDB or RHIDE
>as well.

Yes, your suggestions probably are better. My recommendation of 
fsdb came from the fact, that Peter Restall mentioned, that he was 
cross compiling. I have no experience with this, but I thought 
you will need the djdev package (where fsdb is included), even 
when cross compiling.

I unintentionally ignored, that he also mentioned, that this
was about some 3d engine. So this all might happen in graphics
mode, and stock fsdb can not be used. 

Regards,
Dieter