This is the mail archive of the gcc@gcc.gnu.org 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]

Re: What is acceptable for -ffast-math? (Was: associative law in combine)


<<The _definition_ of "-ffast-math" is "fast and loose". It says so. Try
this:
>>

I hardly thing "fast and loose" is a definition. We know perfectly well 
that there are transformations that Linus would find unacceptable, so no
one is in favor of unrestrained looseness. We are simply (trying to) have
a technical discussion about how loose is loose.

By the way, this entire discussion has been played out in the Ada context,
since in the Ada standard, the two modes are recognized at the standard
level, but the standard does not attempt to define fast and loose.

Note that in classical C, there was no statement about floating-point
accuracy at all. So from a definitional point of view, the compiler could
do anything, but people had some general agreement over what was or was
not appropriate. We are simply trying to reach that general agreement in
this -ffast-math context.

By the way, going back to an earlier post, Linus claims that GCC by default
allows extra precision. That's interesting, since it would mean that on
Power, optimization changes the results. I mentioned earlier that IBM decided
after careful study that this was not acceptable to their numeric users, so
it is interesting for gcc to take an opposite point of view (I suspect that
this was done without careful study :-)

Actually what I had in mind was 80-bit on x86, and I don't think gcc operates
that way by default?


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