This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Revision 162491 -- fortran -fwhole-file regressions

I wrote:

Dave Korn wrote:

Ah, this is Return of the Revenge of PR323 Strikes Back! :-P

Could fortran be made to usefully implement -fexcess-precision=standard?
I'm surprised this hasn't been more of an issue given the prevalence of big
number-crunching apps in the fortran world.

That is because Fortran (the Language) makes no promises. All arithmetic is "an approximation to the mathematically exact result".

Hmm, this apparently shocked everyone so much that - in 3 hours - no rebuttal has been posted.

A rebuttal that could have been as simple as:

Q. Is it Fortran-standard-conforming for the following program:


to print:



A. Yes, this is standard conforming.

[ After all, it's only 25 % off ]

Of course, what this exercise doesn't show is that there is another issue involved, which we - in the Fortran Standardization Committee - identify as "Quality of Implementation (QoI)".

Certainly, a compiler that does the above is standards conforming; it is also useless.

And that's where QoI hits: A compiler *must* give the obvious results to obvious arithmetic requests.

So the question shifts towards: What's obvious ? This is a slippery slope:

1. Should the following program print: " T" for .TRUE. ?

      PRINT*, 1./5. .EQ. 0.2

[ Note: one fifth is not exactly representable in IEEE 754 floating
  point - the division is in most compilers done differently from
  the parsing of the 0.2 constant. ]

2. Should the following program print: " T" for .TRUE. ?

      PRINT*, SIN(4.*ATAN(1.)/6.) .EQ. 0.5

[ Note: 4 atan (1) / 6 is an approximation to 30 degrees in radians - is
  the sine routine "good enough" to reproduce sin(30 degrees) = 1/2 ? ]

What if some of the constants above were read from a file [ so that the routines of GMP and MPFR couldn't be used ] ?

Kind regards,

Toon Moene - e-mail: - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home:; weather:
Progress of GNU Fortran:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]