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