On Mon, 30 Oct 2017, Michael Meissner wrote: > > One obvious possible fix would be for the builtins.def macros never to > > define public names such as sqrtf128 for C++, only ever for C. That would > > be on the basis that C++ code is expected to be using a sqrt overload > > anyway - so making the built-in function available under a public name, in > > the case where __float128 exists for C++, is a matter for libstdc++ > > headers. > > Arghh, yes, I can restrict it to just the C language. Would you prefer just > that? Do we want a target hook to be able to over-ride this on a platform
Yes, I think such a restriction is appropriate (that is, C and ObjC get both sqrtf128 and __builtin_sqrtf128 built-in functions, C++ and ObjC++ get only __builtin_sqrtf128). > basis (with the default behavior only enabling it for C)? If we think that the preferred way for C++ code to access the underlying functions is via function overloads for __float128 (not currently implemented in libstdc++, it seems) rather than suffixed functions, or through accessing the format as long double once that support is working, a target hook may not be neded. If C++ code is expected to use f128-suffixed functions directly, presumably it's desirable for a C++ call to sqrtf128 to be inlined where possible and so you'd want a hook, or some other way of enabling the built-in functions for C++ only in the case where they are usefully distinct from the float / double / long double functions. -- Joseph S. Myers jos...@codesourcery.com
