On Thu, 23 Jun 2016, Bill Schmidt wrote: > After discussing with the glibc folks, I'd like to propose that this patch > be altered to use the 'q' suffix for the builtin names. That way we won't > have a naming conflict with Joseph's patch in the short term, and we'll > be able to stage the movement on trunk to the f128 support. > > I've been informed that there are other packages/libraries that assume > the 'q' suffix, so we will need both anyway. For the time being, we can > use #defines for glibc using GCC 6 to define the f128 functions to be > the q functions. We'll plan to normalize to use the arch-neutral f128 > builtins after the 6.2 push completes.
Those #defines in glibc would be needed anyway for __float128 functions in glibc for x86 to support GCC versions before GCC 7 (which x86 support I'm minded to look at adding once the __float128 functions for powerpc64le are in; adding them for a new architecture shouldn't be hard once the first architecture is done). The 'q' suffix should be considered legacy (just like the __float128 name!), but if it doesn't conflict with the generic support it's essentially a target maintainer matter. As I said in my patch submission for the generic functions, I don't know if target built-in functions can be made into aliases for generic ones, but that's what's desirable in optimization terms once the generic ones are in, so that optimizations apply equally to both. (I'm presuming that eventually we *will* enable all built-in function and other optimizations, that currently are just for float / double / long double, for the new types and their corresponding TS 18661-3 functions as well - that's just lower priority since it's not at all on the critical path for enabling support for the new type, unlike this minimal set of functions.) Do those packages assuming 'q' expect more than the minimal built-in functions (i.e., do they want libquadmath)? I've noted before that while libquadmath is not the way forward for libm support for __float128 (that's *f128 functions in glibc), and while libquadmath is missing the past few years' improvements to glibc libm, enabling it for powerpc64le (once you've got built-in functions and complex arithmetic functions in libgcc) would allow you to test that the back-end __float128 support works for a substantial body of code with __float128 arithmetic.... (While there is no libquadmath testsuite, Paul Murphy's recent work should make it much easier to run the glibc libm-test with libquadmath than it was when libquadmath was first added.) -- Joseph S. Myers jos...@codesourcery.com
