> > On Jun 23, 2016, at 5:41 PM, Joseph Myers <jos...@codesourcery.com> wrote: > > 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.
Agreed! > > (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.) Yes, that's the way we feel too -- it needs to happen, but further down the road once we're out of this bottleneck. > > 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.) Actually libquadmath is what I was thinking of -- there may be more, but I'm not very tuned into this side of things. Once we have the full set of __float128 support in place, we should be able to do some of this kind of testing. Thanks! Bill > > -- > Joseph S. Myers > jos...@codesourcery.com >
