Message-ID: <320F3542.2180@pobox.oleane.com>
Date: Mon, 12 Aug 1996 15:44:34 +0200
From: Francois Charton <deef AT pobox DOT oleane DOT com>
Organization: CCMSA
MIME-Version: 1.0
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
CC: djgpp AT delorie DOT com
Subject: Re: Re : Compiling povray 3.0 with djgpp 2.0
References: <199608121316 DOT PAA12374 AT acp3bf DOT physik DOT rwth-aachen DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hans-Bernhard Broeker wrote:
> 
> Could you please diagnose this a bit further?
> 

Sorry, I did it but forgot to post the info : I had one in "pow" 
function, actually in __ieee_754_pow() function from libm.a. I also got 
an exception somewhere else because I reprogrammed povray *not* to use 
pow (replacing pow(x,y) by exp(y*log(x))) and got another exception when 
compiling with optimisation on... (however, I didn't keep the 
corresponding source and executable).
On the pow problem, I posted something yesterday : which seems to hint a 
defect in libm.a pow() function.

> Generally, I'd suggest to turn off fp exceptions for something like a
> raytracing program, that doesn't actually handle this kind of errors
> anyway, probably. See 'info libc alpha _control87' for details.

This sounds like "hiding the dust under the carpet"... fp exception 
happen because something wrong is happening, probably because either the 
math libraries or the calculation algorithms you use do not handle some 
special case, or have a bug in it. If it is the case, the result of the 
calculations may be wrong... 

Regards, 
F. Charton