On 1/7/24 17:51, Segher Boessenkool wrote:
On Sat, Jan 06, 2024 at 06:02:45PM +0100, David Brown wrote:
On 05/01/2024 19:19, Segher Boessenkool wrote:
That's not the point. A program can be perfectly fine, with bounded
errors and all, and then -ffast-math will typically completely destroy
all that, and replace all arithmetic by the equivalent of a dice roll.
The only difference between IEEE calculations and -ffast-math
calculations is that with IEEE, the ordering and rounding is controlled
and consistent.
No, that is not the only difference.
'-ffast-math'
Sets the options '-fno-math-errno', '-funsafe-math-optimizations',
'-ffinite-math-only', '-fno-rounding-math', '-fno-signaling-nans',
'-fcx-limited-range' and '-fexcess-precision=fast'.
Many of those do much more than what you say, can result in the compiler
generating completely different code.
For any given /single/ arithmetic operation that is
performed, each can have the same amount of rounding error or error due
to the limited length of the mantissa. Agreed?
I don't understand what you mean to say even.
The rounding errors in -ffast-math will be very similar to those in IEEE
mode, for normal numbers.
No, not at all. Look at what -fassociative-math does, for example.
This can **and does** cause the loss of **all** bits of precision in
certain programs. This is not theoretical. This is real.
a = 1e120;
b = 2;
x = (a + b) - a;
IEEE rules will give "x" equal to 1e120 - mathematically /completely/
wrong. -ffast-math will give "x" equal to 2, which is mathematically
precisely correct.
The IEEE result is 0. Which is the **exactly correct** result. This is
a computer program, not some formulas that you can manipulate at will.
That seems to be where the disagreement lies. Those that use -ffast-math
with full knowledge of what it does are presumably acting with the
intent that their program should indeed be treated as "some formulas you
can manipulate at will".
The -ffast-math flag can only reasonably be used with programs that did
not want any specific results anyway. It would be even faster (and just
as correct!) to always return 0.
That is simply wrong.
It is an exaggeration for dramatic effect, but it is fundamentally
correct.
Segher
