https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #24 from joseph at codesourcery dot com <joseph at codesourcery dot 
com> ---
On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:

> > For long double it's sysdeps/ieee754/soft-fp/s_fmal.c in glibc - some 
> > adjustments would be needed to be able to use that as a version for 
> > _Float128 (where sysdeps/ieee754/float128/s_fmaf128.c currently always 
> > uses the ldbl-128 version), in appropriate cases.
> >
> 
> Way to complicated for mere gcc user like myself.
> Hopefully, Thomas Koenig will understand better.

glibc needs to handle a lot of different configurations with various 
choices of supported floating-point types - resulting in complexity around 
how the particular function implementations are chosen for a given system 
- as well as other portability considerations.  There is also complexity 
resulting from the functions covering many different use cases - and thus 
needing to follow all the IEEE 754 requirements for those functions 
although many users may only care about some of those requirements.

> > The underlying arithmetic (in libgcc, not libquadmath) uses the hardware 
> > rounding mode and exceptions (if the x87 and SSE rounding modes disagree, 
> > things are liable to go wrong), via various macros defined in 
> > sfp-machine.h.
> 
> Oh, a mess!
> With implementation that is either 99% or 100% integer being controlled by SSE
> control is WRONG. x87 control word, of course, is no better than SSE.
> But BOTH !!!! I have no words.

Any given libgcc build will only use one of the rounding modes (SSE for 
64-bit, x87 for 32-bit) - but which exception state gets updated in the 
32-bit case depends on whether libgcc was built for SSE arithmetic.

As far as IEEE 754 is concerned, there is only one rounding mode for all 
operations with a binary result (and a separate rounding mode for decimal 
FP results).  As far as the C ABI is concerned, it's not valid for the two 
rounding modes to be different at any ABI boundary; fesetround will always 
set both, while fetestexcept etc. handle both sets of exception flags by 
ORing them together.  *But* glibc's internal optimizations for code that 
saves and restores floating-point state internally try to manipulate only 
SSE state, or only x87 state, in functions that should only use one of 
those two sets of state, so code called from within those functions may 
need to work properly when the two rounding modes are different.  
Together with the above point about which exception state gets used in 
libgcc support for _Float128, this results in those optimizations, in the 
float128 case, sometimes only needing to handle SSE state but sometimes 
needing to handle both sets of state (see glibc's 
sysdeps/x86/fpu/fenv_private.h).

Reply via email to