On Fri, Jul 17, 2026 at 11:23:50AM +0200, Tomasz Kaminski wrote:
> Thanks Jakub. For the time being I will use -fexcess-precision=standard
> in these tests, as I think that the difference is caused by the ostream
> operators
> producing different result when excess precision is enable for decimal
> output.
> I think this distributions should use hexfloat ouput in first place, but
> that was not
> the scope of the patch.
Note, -fexcess-precision=standard doesn't mean no excess precision, but
instead a predictable one (e.g. on i686 with the exception of -msse2
-mfpmath=sse means constants and all operations are performed as if in the
long double precision, explicit casts and assignments to float/double
do convert to smaller precision).
There is no way to get the exactly same behavior as one gets on non-excess
precision targets, even when adding tons of (float) or (double) casts,
on constants and on every single arithmetic result (or using temporaries
for everyhthing), there is double rounding (the constants are first rounded
to long double, then rounded to whatever you cast it to, or arithmetics
first rounded to long double, then rounded to whatever you cast it to), but
it can be closer to what you get without excess precision.
The -fexcess-precision=fast case (default for -std=gnu++*) is unpredictable,
constants don't have excess precision, but for arithmetics, if the compiler
happens to keep the result in x86 floating point stack until next operation,
it has long double precision, if it needs to spill it at some point in
between, it is rounded to float/double (whatever the type of the aritmetics
is).
So, if you have
float x, y;
...
x = (x + 1.23456789123456789123456789f) - y;
then to get something closer to no excess precision, one could use
either
x = (float) (x + (float) 1.23456789123456789123456789f) - y;
or
x = x + (float) 1.23456789123456789123456789f;
x = x - y;
Jakub
