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

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Brad Lucier wrote:

> Toon Moene wrote:
> 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:
No, your mixing "undefined behaviour" with "yields a processor-dependent 
approximation to".  Undefined behaviour in Fortran speak means: The 
`processor' (compiler+assembler+linker+OS+hardware) can do what it likes 
with your program, because it just broke the rules.

Computations yielding a processor-dependent approximation to (some 
mathematical construct) might seem to give the processor a lot of room, 
but in general it's considered a quality-of-implementation `issue' if 
1.0+1.0 does not equal 2.0.

> 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.
As Craig Burley noticed back in '99 when we discussed this for the first 
time, the problem is not so much that you do not always get the same 
value from a computation when compiling with different optimizations or 
using different versions of the compiler, but the fact that you 
sometimes do not get the same value in a compilation unit, period 
(there's no "referential transparency").

Fixing this by spilling with extended precision will not be easy, 
because basically, the i386 backend (config/i386/i386.{c|h|md} is lying 
to the rest of the compiler when it says that it accepts insns with 
SFmode en DFmode operands, because it will happily stuff them into 
instructions that use XFmode arithmetic.

> 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*.
Well, I'd say that if people use Fortran 77, they should either (1) know 
the model of arithmetic it supplies and adhere to that or (2) be aware 
that they are using an extension to Fortran 77 and indicate that they 
are aware of that by using a compile time switch.  We're not taking away 
anything from them here.

--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)