Remove LIBGCC2_TF_CEXT target macro

Jeff Law
Thu Sep 18 23:23:00 GMT 2014

On 09/16/14 15:41, Joseph S. Myers wrote:
> This patch removes the (undocumented) LIBGCC2_TF_CEXT target macro,
> replacing it by -fbuilding-libgcc predefines (and thereby gets rid of
> another LIBGCC2_LONG_DOUBLE_TYPE_SIZE conditional, though some more
> patches are needed before that target macro can be eliminated).  This
> macro indicated the suffix used on __builtin_huge_val,
> __builtin_copysign, __builtin_fabs built-in function names to produce
> the names for a given floating-point mode.
> Predefines are added for all floating-point modes supported for
> libgcc, not just TFmode.  These are fully accurate for modes
> corresponding to float, double and long double.  For other modes, the
> suffix for *constants* is determined by the targetm.c.mode_for_suffix
> hook (the limit to two possible suffixes 'w' and 'q' being hardcoded
> in various places).  This is in fact the suffix for built-in functions
> as well where such functions exist.
> * For i386, the *q functions always exist (whether or not TFmode is
>    used for long double).  The *w functions never exist (but this
>    doesn't matter for libgcc, since no i386 configuration treats XFmode
>    as a supported scalar mode if long double is TFmode; if __float80
>    were to be supported for 64-bit Android, properly such functions
>    ought to be added).
> * For ia64, the *q functions exist for non-HP-UX (under HP-UX, long
>    double is TFmode, so they aren't needed).  The *w functions never
>    exist.  This is an issue for this libgcc code for the XFmode complex
>    functions in libgcc on HP-UX; as I understand it, right now those
>    will accidentally be using TFmode versions of those three functions,
>    so involving unnecessary conversions, while the sanity check on CEXT
>    accidentally passes because all it tests is the sizes of the types.
> Because of the lack of 'w' functions, the patch uses 'l' when the
> constant suffix is 'w', matching what the existing libgcc code would
> do for IA64 HP-UX in that case.
> Ideally there would be generic code to create such built-in functions
> for all supported floating-point types.  That may be something to
> consider if support for TS 18661-3 (standard bindings for IEEE
> 754-2008, defining names such as _Float128, and function names such as
> copysignf128) is added in future.
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
> commit?
> gcc:
> 2014-09-16  Joseph Myers  <>
> 	* system.h (LIBGCC2_TF_CEXT): Poison.
> 	* config/i386/cygming.h (LIBGCC2_TF_CEXT): Remove.
> 	* config/i386/darwin.h (LIBGCC2_TF_CEXT): Likewise.
> 	* config/i386/dragonfly.h (LIBGCC2_TF_CEXT): Likewise.
> 	* config/i386/freebsd.h (LIBGCC2_TF_CEXT): Likewise.
> 	* config/i386/gnu-user-common.h (LIBGCC2_TF_CEXT): Likewise.
> 	* config/i386/openbsdelf.h (LIBGCC2_TF_CEXT): Likewise.
> 	* config/i386/sol2.h (LIBGCC2_TF_CEXT): Likewise.
> 	* config/ia64/ia64.h (LIBGCC2_TF_CEXT): Likewise.
> 	* config/ia64/linux.h (LIBGCC2_TF_CEXT): Likewise.
> gcc/c-family:
> 2014-09-16  Joseph Myers  <>
> 	* c-cppbuiltin.c (c_cpp_builtins): Define __LIBGCC_*_FUNC_EXT__
> 	for supported floating-point modes.
> libgcc:
> 2014-09-16  Joseph Myers  <>
> 	* libgcc2.c (CEXT): Define using __LIBGCC_*_FUNC_EXT__.

More information about the Gcc-patches mailing list