Xref:	news2.mv.net comp.os.msdos.djgpp:4579
From:	Broeker AT PROBLEM_WITH_INEWS_DOMAIN_FILE (Hans-Bernhard Broeker)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: More buggy libm
Date:	3 Jun 1996 14:32:55 GMT
Organization:	RWTH -Aachen / Rechnerbetrieb Informatik
Lines:	32
Message-ID:	<4out2n$cjs@news.rwth-aachen.de>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 960602101747 DOT 19090R-100000 AT is>
NNTP-Posting-Host:	axpcl1.physik.rwth-aachen.de
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) wrote:

> On Fri, 31 May 1996, Thomas Demmer wrote:

> > Optimization     libm      Result
> >   none            no        1 flaw
> >   none            yes       1 flaw (same as above)
> >    -O1            no        hung

> Paranoia is not supposed to be compiled with optimizations.  Don't expect 
> anything except trouble when you do that.

And it is also known to fail for FPU's that do their calculations with
more precision than the stored data types (float, double) can actually
hold (the 387 and it's successors always calculate to 'long double',
a.k.a. 'temp real' precision, i.e. they always use the internal 80-bit
format to calculate values, and only transform to 64 bit (double) or
32 bit (float) formats when storing values back into memory). This is
even reported by paranoia at or before the point of that
'flaw'. You'll probably have to reconfigure the FPU (or even change
the opcodes DJGPP uses for 'fadd', 'fdiv' and such operations) to
prevent this 'flaw' from being reported.

Summing it up, the paranoia result has almost nothing to do with the
compiler (or libm, or even OS) you used to compile it. It is only
dependent on the actual FP processing hard/software, because that's
what it was designed to check. Any other dependence would be a bug in
paranoia.

Hans-Bernhard Broeker (Aachen, Germany)

- Raw text -