public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* paranoia results (C and Fortran)
@ 1999-07-12 16:55 Emil Hallin
  0 siblings, 0 replies; 2+ messages in thread
From: Emil Hallin @ 1999-07-12 16:55 UTC (permalink / raw)
  To: egcs-bugs

Hi,
The recent posting of fortran paranoia prompted me to look at the
results of both the C and the fortran versions using gcc version 2.96
19990711 (experimental) and GNU Fortran 0.5.25 19990711 (experimental)
on a PIII Linux box (Linux 2.2.5-22 #1 Wed Jun 2 09:17:03 EDT 1999 i686
unknown). Both these codes produce no flaws and no defects running under
MS windows compilers (Watcom and MS VC6). 

On Linux, the results are:
output of paranoia.c (no optimization):

DEFECT:  Calculated 7.38905609548934539e+00 for
	(1 + (-1.11022302462515654e-16) ^ (-1.80143985094819840e+16);
	differs from correct value by -3.44130679508225512e-09 .
	This much error may spoil financial
	calculations involving tiny interest rates.
Checking rounding on multiply, divide and add/subtract.
* is neither chopped nor correctly rounded.
/ is neither chopped nor correctly rounded.
Addition/Subtraction neither rounds nor chops.
Sticky bit used incorrectly or not at all.
FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.

output of fortran version of paranoia(-O2 -ffloat-store
-funroll-all-loops -mpentiumpro):

 DEFECT: Calculated (1-0.11102230E-15)**(-0.18014399E+17)
         differs from correct value by -0.34413068E-08
 This much error may spoil calculations such as compounded interest.

 CHECKING FOR ROUNDING IN MULTIPLY, DIVIDE AND ADD/SUBTRACT:
  MULTIPLICATION IS NEITHER CHOPPED NOR CORRECTLY ROUNDED.
  DIVISION IS NEITHER CHOPPED NOR CORRECTLY ROUNDED.
  Vector/Scalar Division not rounded or chopped
  ADD/SUBTRACT IS NEITHER CHOPPED NOR CORRECTLY ROUNDED.
  STICKY BIT USED INCORRECTLY OR NOT AT ALL.
 One flaw assessed for failure of a guard or rounding test.



Applying *any* level of optimization (O1-O5) to the C code results in a
multitude of serious defects according to the paranoia program, and the
for structure on line 1606 of the code becomes an infinite loop.
Applying any level of optimization to the Fortran code has no harmful
side effect.

Enclosed is a tar-ball containing the following files:

command_line_output: 	command line used to compile the code
paranoia.i
paranoia.c
results:		the results of Fortran (optimized) and C (not
			optimized) paranoia
optimized_results:	the "bad" results when optimization is turned on
system:			the output from "uname -a"

Not sure how this rates on the bug scale, but thought these results
might be interesting to some folks.
	emil
paranoia.tar.gz


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: paranoia results (C and Fortran)
@ 1999-07-31 23:33 N8TM
  0 siblings, 0 replies; 2+ messages in thread
From: N8TM @ 1999-07-31 23:33 UTC (permalink / raw)
  To: emil, egcs-bugs

In a message dated 7/12/99 4:06:28 PM PST, emil@cls.usask.ca writes:

> DEFECT:  Calculated 7.38905609548934539e+00 for
>  	(1 + (-1.11022302462515654e-16) ^ (-1.80143985094819840e+16);
>  	differs from correct value by -3.44130679508225512e-09 .
>  	This much error may spoil financial
>  	calculations involving tiny interest rates.
 This would mean that you're using an unsatisfactory implementation of pow(). 
 That's not directly under the control of egcs.  I've worked out a powl() for 
686 which passes all the usual tests, but I haven't detected any interest in 
that.  Definitely getting off-topic.


>>* is neither chopped nor correctly rounded.
/ is neither chopped nor correctly rounded.
Addition/Subtraction neither rounds nor chops.
Sticky bit used incorrectly or not at all.
FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.

This simply means that you're invoking double rounding by running an x86 in 
default mode, which rounds to 64 bits mantissa, and following up by rounding 
to 53 bits.  It's not the fault of egcs that this is a useful mode for 
running this processor family.  Set it to 53-bit rounding mode if you don't 
like it, as certain other compilers do.  When you run in single (float) 
precision, you don't see this problem, as the 64-bit mantissa arithmetic 
doesn't drop any bits.

Tim
tprince@computer.org


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-07-31 23:33 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-12 16:55 paranoia results (C and Fortran) Emil Hallin
1999-07-31 23:33 N8TM

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).