On 09.09.22 10:10, Andrew Stubbs wrote:
On 08.09.22 22:38, Kwok Cheung Yeung wrote:
The instructions for the transcendental functions are documented to have limited numerical precision, so they are only used if unsafe_math_optimizations are enabled for now.

-funsafe-math-optimizations implies -fno-signed-zeros, -fno-trapping-math, -fassociative-math,
and -freciprocal-math. All of them reduce precision and my violate IEEE or ISO/language standards.

However, I think it is rather surprising to have all of the sudden only a precision of the
order of 100,000,000 ULP instead of ~4 ULP as to be expected. That's a precision loss of the
order of 10^8 or 2^29 which is huge!

For program deliberately using double precision, it can be too much – even if they do not need
double precision in reality. (Weather forecast system recently moved to single precision as the
quality is similar and benefits of faster results/finer grids or longer forecast times prevail.)

As this behavior is highly surprising, I think it should be at least documented.

In https://gcc.gnu.org/PR105246 , I suggested a new flag (such as -mpermit-reduced-precision) to
make it possible turn it on/off explicitly (might be still enabled by -funsafe-math-optimizations);
alternatively, it could also be handled as initial guess for the result which is then refined
in some iteration steps. (It could also be combined to give the user the choice.)

While still being convinced that a flag makes more sense than just documenting it,
I have nonetheless attached a documentation attempt.

Thoughts?

Tobias


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955