Add __builtin_tgmath for better tgmath.h implementation (bug 81156).

Various implementations of C99/C11 <tgmath.h> have the property that
their macro expansions contain many copies of the macro arguments, so
resulting in exponential blowup of the size of macro expansions where
a call to such a macro contains other such calls in the macro
arguments.

This patch adds a (C-only) language feature __builtin_tgmath designed
to avoid this problem by implementing the <tgmath.h> function
selection rules directly in the compiler.  The effect is that
type-generic macros can be defined simply as

#define pow(a, b) __builtin_tgmath (powf, pow, powl, \
                                    cpowf, cpow, cpowl, a, b)

as in the example added to the manual, with each macro argument
expanded exactly once.  The details of __builtin_tgmath are as
described in the manual.  This is C-only since C++ uses function
overloading and just defines <ctgmath> to include <ccomplex> and
<cmath>.

__builtin_tgmath handles C99/C11 type-generic macros, and _FloatN,
_FloatNx and decimal floating-point types (following the proposed
resolution to the floating-point TS DR#9 that makes the rules for
finding a common type from arguments to a type-generic macro follow
the usual arithmetic conversions after adjustment of integer arguments
to _Decimal64 or double - or to _Complex double in the case of GNU
complex integer arguments).

Type-generic macros for functions from TS 18661 that round their
results to a narrower type are handled, but there are still some
unresolved questions regarding such macros so further changes in that
regard may be needed in future.  The current implementation follows an
older version of the DR#13 resolution (allowing a function for a
wide-enough argument type to be selected if no exactly-matching
function is available), but with appropriate calls to __builtin_tgmath
is still fully compatible with the latest version of the resolution
(not yet in the DR log), and allowing such not-exactly-matching
argument types to be chosen in that case avoids needing another
special case to treat integers as _Float64 instead of double in
certain cases.

Regarding other possible language/library features, not currently
implemented in GCC:

* Imaginary types could be naturally supported by allowing cases where
  the type-generic type is an imaginary type T and arguments or return
  types may be T (as at present), or the corresponding real type to T
  (as at present), or (new) the corresponding real type if T is real
  or imaginary but T if T is complex.  (tgmath.h would need a series
  of functions such as

  static inline _Imaginary double
  __sin_imag (_Imaginary double __x)
  {
    return _Imaginary_I * sinh (__imag__ __x);
  }

  to be used in __builtin_tgmath calls.)

* __builtin_tgmath would use the constant rounding direction in the
  presence of support for the FENV_ROUND / FENV_DEC_ROUND pragmas.
  Support for those would also require a new __builtin_<something> to
  cause a non-type-generic call to use the constant rounding
  direction (it seems cleaner to add a new __builtin_<something> when
  required than to make __builtin_tgmath handle a non-type-generic
  case with only one function argument).

* TS 18661-5 __STDC_TGMATH_OPERATOR_EVALUATION__ would require new
  __builtin_<something> that evaluates with excess range and precision
  like arithmetic operators do.

* The proposed C bindings for IEEE 754-2018 augmented arithmetic
  operations involve struct return types.  As currently implemented
  __builtin_tgmath does not handle those, but support could be added.

There are many error cases that the implementation diagnoses.  I've
tried to ensure reasonable error messages for erroneous uses of
__builtin_tgmath, but the errors for erroneous uses of the resulting
type-generic macros (that is, when the non-function arguments have
inappropriate types) are more important as they are more likely to be
seen by users.

GCC's own tgmath.h, as used for some targets, is updated in this
patch.  I've tested those changes minimally, via adjusting
gcc.dg/c99-tgmath-* locally to use that tgmath.h version.  I've also
run the glibc testsuite (which has much more thorough tests of
correctness of tgmath.h function selection) with a glibc patch to use
__builtin_tgmath in glibc's tgmath.h.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

	PR c/81156

gcc:
	* doc/extend.texi (Other Builtins): Document __builtin_tgmath.
	* ginclude/tgmath.h (__tg_cplx, __tg_ldbl, __tg_dbl, __tg_choose)
	(__tg_choose_2, __tg_choose_3, __TGMATH_REAL_1_2)
	(__TGMATH_REAL_2_3): Remove macros.
	(__TGMATH_CPLX, __TGMATH_CPLX_2, __TGMATH_REAL, __TGMATH_REAL_2)
	(__TGMATH_REAL_3, __TGMATH_CPLX_ONLY): Define using
	__builtin_tgmath.
	(frexp, ldexp, nexttoward, scalbn, scalbln): Define using
	__TGMATH_REAL_2.
	(remquo): Define using __TGMATH_REAL_3.

gcc/c:
	* c-parser.c (check_tgmath_function): New function.
	(enum tgmath_parm_kind): New enum.
	(c_parser_postfix_expression): Handle __builtin_tgmath.

gcc/c-family:
	* c-common.c (c_common_reswords): Add __builtin_tgmath.
	* c-common.h (enum rid): Add RID_BUILTIN_TGMATH.

gcc/testsuite:
	* gcc.dg/builtin-tgmath-1.c, gcc.dg/builtin-tgmath-2.c,
	gcc.dg/builtin-tgmath-err-1.c, gcc.dg/builtin-tgmath-err-2.c,
	gcc.dg/dfp/builtin-tgmath-dfp-err.c,
	gcc.dg/dfp/builtin-tgmath-dfp.c: New tests.

From-SVN: r254749

1 files changed, 57 insertions, 0 deletions

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c6bdb86..711264c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -11684,6 +11684,63 @@ future revisions.
 
 @end deftypefn
 
+@deftypefn {Built-in Function} @var{type} __builtin_tgmath (@var{functions}, @var{arguments})
+
+The built-in function @code{__builtin_tgmath}, available only for C
+and Objective-C, calls a function determined according to the rules of
+@code{<tgmath.h>} macros.  It is intended to be used in
+implementations of that header, so that expansions of macros from that
+header only expand each of their arguments once, to avoid problems
+when calls to such macros are nested inside the arguments of other
+calls to such macros; in addition, it results in better diagnostics
+for invalid calls to @code{<tgmath.h>} macros than implementations
+using other GNU C language features.  For example, the @code{pow}
+type-generic macro might be defined as:
+
+@smallexample
+#define pow(a, b) __builtin_tgmath (powf, pow, powl, \
+                                    cpowf, cpow, cpowl, a, b)
+@end smallexample
+
+The arguments to @code{__builtin_tgmath} are at least two pointers to
+functions, followed by the arguments to the type-generic macro (which
+will be passed as arguments to the selected function).  All the
+pointers to functions must be pointers to prototyped functions, none
+of which may have variable arguments, and all of which must have the
+same number of parameters; the number of parameters of the first
+function determines how many arguments to @code{__builtin_tgmath} are
+interpreted as function pointers, and how many as the arguments to the
+called function.
+
+The types of the specified functions must all be different, but
+related to each other in the same way as a set of functions that may
+be selected between by a macro in @code{<tgmath.h>}.  This means that
+the functions are parameterized by a floating-point type @var{t},
+different for each such function.  The function return types may all
+be the same type, or they may be @var{t} for each function, or they
+may be the real type corresponding to @var{t} for each function (if
+some of the types @var{t} are complex).  Likewise, for each parameter
+position, the type of the parameter in that position may always be the
+same type, or may be @var{t} for each function (this case must apply
+for at least one parameter position), or may be the real type
+corresponding to @var{t} for each function.
+
+The standard rules for @code{<tgmath.h>} macros are used to find a
+common type @var{u} from the types of the arguments for parameters
+whose types vary between the functions; complex integer types (a GNU
+extension) are treated like @code{_Complex double} for this purpose.
+If the function return types vary, or are all the same integer type,
+the function called is the one for which @var{t} is @var{u}, and it is
+an error if there is no such function.  If the function return types
+are all the same floating-point type, the type-generic macro is taken
+to be one of those from TS 18661 that rounds the result to a narrower
+type; if there is a function for which @var{t} is @var{u}, it is
+called, and otherwise the first function, if any, for which @var{t}
+has at least the range and precision of @var{u} is called, and it is
+an error if there is no such function.
+
+@end deftypefn
+
 @deftypefn {Built-in Function} @var{type} __builtin_complex (@var{real}, @var{imag})
 
 The built-in function @code{__builtin_complex} is provided for use in