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: # Re: [RFD] -ffinite-math-only.

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 - - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77:
Join GNU Fortran 95: (under construction)

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