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: 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)