# Re: [RFD] -ffinite-math-only.

[Brad Lucier]

Toon Moene wrote:

> Yep, I'm fully aware of that, and I *am* doing this because I do not want
> to perpetrate the myth that a Fortran 77 compiler can `somehow' be IEEE
> conformant.

I don't want to start a flamefest (this is a technical question), but I
think this empty rhetoric.  Sun has been supporting an IEEE-conforming
F77 compiler since at least 1992, and perhaps back to 1987 on Motorola 
68020-based hardware.

> This all is not new, of course.  In '97 we introduced alias analysis based
> on the observation that in Fortran dummy arguments, common block entities
> and local entities cannot overlap (work done by John Carr).  Obviously,
> this would invalidate code by people who invoked undefined behaviour here.
> However, this cannot stop us - we provide compile time options so that
> those users can keep running their software.

I consider this to be an invalid analogy.  The rules about aliasing
were introduced *specifically* to allow better compiler optimizations.
The standard was basically telling programmers "Don't do that" or, more
precisely, "Don't presume that this is true."  The aliasing rule is similar
to the rule that the values of local variables are not preserved between
function calls unless the SAVE statement is used.

I consider the finite-math-only situation to be analogous to the following
situations, which also lead to undefined behavior in Fortran 77, and which
also affect the results of floating-point arithmetic:

1.	Multiplication by 1.0 leads to undefined behavior.  Twenty years
	ago there were machines with conforming Fortran compilers for which
	1.0 * x did not equal x.  Do we want GCC to have a flag to allow this,
	even if it leads to faster code (with soft-float, for example)?
	I think not.

2.	Calculating sqrt(x) or any trigonometric function leads to
	undefined behavior.  Nothing is specified about the precision
	or accuracy of these functions.  Do we want GCC (or our libraries)
	to have a flag to calculate these functions to less than maximal
	precision if this leads to faster code in some situations?
	Probably yes.  Do we want this to be the default?  Probably not.

3.	Calculating a*b+c (where these are double precision variables) leads
	to undefined behavior in GCC f77 on *87.  If a*b is spilled to the
	stack before addition to c, it is spilled in double precision, not
	extended precision, so one gets different answers depending on whether
	a*b is spilled before being added to c.  Should one have a
	flag specifying that spills are extended-precision accurate?  I have
	always argued yes; Richard Henderson used to argue no, but from a
	recent post to one of the GCC lists, I understand that he now thinks
	the answer is yes.  Should double-precision spills be the default, even
	if it leads to different answers and to less accurate answers in some
	cases? Probably yes.

For all these questions, one balances the needs for precision, accuracy,
and speed, and comes up with an answer specific to the situation.

So I would pose the finite-math-only question as follows:

4.	Dividing 1.0/0.0 or 0.0/0.0 leads to undefined behavior
	(just as in 1--3 above) and may give different answers on different
	Fortran systems.  If we assume that expressions like these that
	can generate IEEE 754 infinities and NaNs do not arise in our code,
	then we can generate faster code.  If we're wrong, we also get
	different answers with an -O2 compile than with an -O0 compiler, we
	get different answers from the hardware model that people have in
	their head for almost any currently available, generally used
	microprocessor, and we cannot use part of the available hardware
	support for floating-point arithmetic on these processors.  Should we
	have a flag that enables this behavior?  Probably yes.  Should this be
	the default behavior in F77?  I would say *no*.

> The only way to get the treatment of IEEE-754 conformance correct in
> Fortran is to wait for the upcoming Fortran 2004 Standard, which will
> detail the exact way in which to write programs that use non-finite math as
> offered by IEEE-754 conformant hardware.  Because of this, I want to have
> language hooks, because Fortran 2004 will need IEEE-754 conformance on a
> per-compilation-unit basis.

It is now 7 years after the Fortran 95 standard, and we have no Fortran 95
front end in GCC.  Your statement above implies to me that you're willing
to weaken the default support for IEEE 754 in GCC Fortran (at least) until
there's a F04 (year-2000 problem there ;-) front end in GCC.  It could very
well happen that we don't have an F04 front end until 2011, seven years after
the standard is adopted (and the most-recent Fortran standard slipped
its schedule badly).  Moving backwards from better default IEEE 754 compliance
for the next nine years and then expecting to implement strict conformance
on top of the then-current code base seems like the wrong way to go.

Brad