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

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Mon, Oct 30, 2017 at 06:32:44PM +0000, Joseph Myers wrote:
> 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.

This patch fixes exporting the non __builtin_ names to be done by default only
for the C language.  I added a target hook in case a port needs to enable
built-ins for C++ (either wholesale, or for particular built-in functions).

I have done a bootstrap on a little endian Power8 system and it had no
regressions.  The x86-64 bootstrap just entered stage3.  Assuming there are no
regressions on x86-64, can I check this patch into the trunk?

2017-10-30  Michael Meissner  <meissner@linux.vnet.ibm.com>

	* builtins.def (DEF_FLOATN_BUILTIN): Change most _Float<N> and
	_Float<N>X built-in functions so that the variant without the
	"__builtin_" prefix is only enabled for the GNU C language when it
	is non-strict ANSI/ISO mode.
	(DEF_EXT_LIB_FLOATN_NX_BUILTINS): Likewise.
	* target.def (floatn_builtin_p): Add a target hook to control
	whether _Float<N> and _Float<N>X built-in functions without the
	"__builtin_" prefix are enabled.  Include langhooks.h in
	targhooks.c.
	* targhooks.h (default_floatn_builtin_p): Likewise.
	* targhooks.c (default_floatn_builtin_p): Likewise.
	* doc/tm.texi.in (TARGET_FLOATN_BUILTIN_P): Document the
	floatn_builtin_p target hook.
	* doc/tm.texi (TARGET_FLOATN_BUILTIN_P): Likewise.

-- 
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

Attachment: ieee128-patch50b
Description: Text document