This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [testsuite gfortran] partial fix for secnds*.f
- From: dominiq at lps dot ens dot fr (Dominique Dhumieres)
- To: tprince at computer dot org, dominiq at lps dot ens dot fr
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Mon, 28 May 2007 23:58:28 +0200
- Subject: Re: [testsuite gfortran] partial fix for secnds*.f
- References: <20070528181820.2DDE15BB6C@mailhost.lps.ens.fr> <465B4316.2010708@myrealbox.com>
> Not at all, what was known in ancient times has been confirmed
> repeatedly.
Yes indeed, but a property of youth is to ignore "ancient times"!
> Ignoring this rule, while it sometimes could be done safely
> in extra precision x87 code, compounded the confusion encountered by
> those who didn't care to pay attention.
This allows the nicety that just hit me:
if (((dat2 - dat1) < t2a) .or. ((dat2 - dat1) > t2)) then
count2 = count2 + 1
print '(5(1PG20.10))', t2a, dat2-dat1, t2, dat1, dat2
print *, (dat2 - dat1)-t2a, (dat2 - dat1)-t2
end if
gives
0.2621874809 0.2621874809 0.2621874809 -0.1171875000 0.1449999958
1.4901161E-08 1.4901161E-08
0.2639999986 0.2639999986 0.2639999986 0.1449999958 0.4090000093
1.4901161E-08 1.4901161E-08
if not compiled with -ffloat-store!
> Now, it is more important than
> ever to avoid sloppy code which gives different results according to
> precision of intermediate evaluation.
Even if you use the same precision everywhere, the result can still
depend on the order of the evaluation as shown by the secnds*.f tests.