Re: [PATCH, version 5a], Add support for _Float<N> and _Float<N>X sqrt, fma, fmin, fmax built-in functions

[Michael Meissner <meissner@linux.vnet.ibm.com>]

On Mon, Oct 30, 2017 at 04:16:42PM +0000, Joseph Myers wrote:
> This has broken building the mainline glibc testsuite with GCC mainline 
> for platforms where long double has binary128 format.
> 
> Recall that _FloatN type names are not supported for C++, because of the 
> expectation that any C++ bindings for such types would be class-based like 
> the TR 24733 DFP support rather than using built-in types such as 
> _Float128.  Thus glibc uses __float128 to define _Float128 internally for 
> C++ where __float128 is available, but where it is not available but long 
> double has that format, the headers use long double to implement 
> _Float128.  Thus you get conflicting declarations, headers declaring 
> sqrtf128 to use a typedef for long double but the built-in functions using 
> the internal _Float128 type that has no built-in name referring directly 
> to it for C++.
> 
> 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
basis (with the default behavior only enabling it for C)?

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797