Bug 45175

Summary:	In gfortran, the calculation of small differences seems to depend on optimization flags
Product:	gcc	Reporter:	Dave Newton <CycleTimeChart>
Component:	fortran	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	166255, 36876, adam, AlekM, anoullez, benoit.sibaud, bernert, birger.b, brad_atcheson, brooks, cognot, csk, CycleTimeChart, debian-gcc, denis.nagorny, deshpand, doko, dsell, dyang, eda-qa, fang, gbburkhardt, gcc-bugs, gcc-erikd, gcczilla1, Graham.Murphy, green, gsinai, gtalbot, have, hjl.tools, ich, ismail, jmurray, konstantin, lani, macracan, mbrudka, mehta, neff.kevin, nicos, nikos42, nouiz, npr1, olcios, P.Schaffnit, paul_blankenbaker, pepalogik, petr.savicky, piaget, pr2345, preciseflight, purnnam1, roebel, rohit.x.tripathi, rozenman, sk2alexa, sliwa, sunjoong, themis_hv, tjf, tterribe, tydeman, u.strempel, vincent-gcc, whaley, wirawan0, xiaoyi_wu, ywei
Priority:	P3
Version:	4.5.0
Target Milestone:	---
Host:		Target:
Build:		Known to work:
Known to fail:		Last reconfirmed:
Attachments:	Main program Support routines Implicit typecasting include file Compilation batch file

Description Dave Newton 2010-08-04 02:03:25 UTC

Just a little background:

I wrote a program that does high accuracy factorials.  It saves a given factorial for later use as a double precision real between 1 and 2 and an integer power of 2.  It does this by calculating the factorial to a practically unlimited number of bits, rounding it to 53 bits only as the final step, thereby avoiding the cumulative round off errors that occur.

I wanted to compare the accuracy of this method to a straight-forward way of calculating factorials.  So I also scaled factorials calculated in a straight-forward way the same way as above, that is as a double precision real between 1 and 2 and an integer power of 2.

In the comparison, the integer power of 2 can be ignored, as it is practically always the same.  As to the real portion, the difference between the two reals should always be an integer multiple of 2**(-52).  The crux of the bug is that when I compiled using the flag -O, this was true.  Using -O2, it was not.  Stated another way, the calculation of small differences seems to depend on optimization flags.

Comment 1 Dave Newton 2010-08-04 02:05:14 UTC

Created attachment 21388 [details]
Main program

Comment 2 Dave Newton 2010-08-04 02:05:50 UTC

Created attachment 21389 [details]
Support routines

Comment 3 Dave Newton 2010-08-04 02:06:39 UTC

Created attachment 21390 [details]
Implicit typecasting include file

Comment 4 Dave Newton 2010-08-04 02:22:27 UTC

Created attachment 21391 [details]
Compilation batch file

Comment 5 Dominique d'Humieres 2010-08-04 02:38:13 UTC

You do not say on which platform you did the tests (gfortran -v). From

C:\FI\Implicit4.inc

I assume that you are using some *86* processor under Windows. 

This is not a gfortran bug, but a duplicate of an infamous pr I cannot find the number. You should try -ffloat-store or -mfpmath=sse and have a look at the gcc manual

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

under -ffloat-store and -fexcess-precision=style.

Comment 6 Jerry DeLisle 2010-08-04 02:42:02 UTC

This is a duplicate of PR 323

See  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Just use -ffloat-store.



*** This bug has been marked as a duplicate of 323 ***