https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #23 from Michael_S <already5chosen at yahoo dot com> --- (In reply to jos...@codesourcery.com from comment #22) > On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote: > > > > The function should be sqrtf128 (present in glibc 2.26 and later on > > > x86_64, x86, powerpc64le, ia64). I don't know about support in non-glibc > > > C libraries. > > > > x86-64 gcc on Godbolt does not appear to know about it. > > I think, Godbolt uses rather standard Linux with quite new glibc and > > headers. > > https://godbolt.org/z/Y4YecvxK6 > > Make sure to define _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__ to > get these declarations. > Thank you. It made a difference on Goldbolt. Does not help MSYS2, but at least I will be able to test on Linux. > > May be. I don't know how to get soft-fp version. > > 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. > > It seems, you didn't pay attention that in my later posts I am giving > > implementations of binary128 *division* rather than sqrtq(). > > Ah - binary128 division is nothing to do with libquadmath at all (the > basic arithmetic operations go in libgcc, not libquadmath). Using a PR > about one issue as an umbrella discussion of various vaguely related > things is generally confusing and unhelpful to tracking the status of what > is or is not fixed. You are right. Again, hopefully, Thomas Koenig will open a thread in which a discussion of all issues related to libquadmath and binary128 will be on topic. But, formally speaking, slowness of division or of fma are not bugs. So, may be, there are better places than bugzilla to discuss them. I just don't know what place it is. The good thing about bugzilla is a convenient forum-like user interface. > > In general, working out how to optimize the format-generic code in soft-fp > if possible would be preferred to writing format-specific implementations. > Note that for multiplication and division there are already various > choices of implementation approaches that can be selected via macros > defined in sfp-machine.h. > I am not sure that I like an idea of format-generic solution for specific case of soft binary128. binary128 isvery special, because it is the smallest. It can gain ALOT of speed from format-specific handling. Not sure if 3x, but pretty certain about 2x. > > BTW, I see no mentioning of rounding control or of any sort of exceptions in > > GCC libquadmath docs. No APIs with names resembling fesetround() or > > mpfr_set_default_rounding_mode(). > > 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. Hopefully, libquadmath is saner than that, but I am unable to figure it out from docs.
