[Bug c/81156] GCC fails to compile a formula with tgmath.h

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81156

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
My notion of __builtin_tgmath is something like

__builtin_tgmath (0, powf, pow, powl, cpowf, cpow, cpowl, a, b)

where the arguments are: an integer constant expression to distinguish 
different cases of type-generic rules (0 for normal rules, 1 reserved to 
mean __STDC_TGMATH_OPERATOR_EVALUATION__ rules, other values reserved for 
any other cases needed in future); the possible functions to use, in any 
order (function pointers; only the selected one gets evaluated); the 
function arguments (with a requirement that the first argument can't be a 
function pointer), in the order in which they are passed to the function.  
To be clear, __builtin_tgmath would be a keyword, like various other 
__builtin_*, not actually a built-in function (and it would be C-only, 
since C++ has existing mathematical function overloads and its own 
tgmath.h specification in C++11 and later; I doubt the existing C tgmath.h 
works properly for C++ anyway).

Ignoring imaginary types, that's sufficient information to determine which 
arguments (and return value if applicable) are type-generic, and which 
function to call, and to give much better errors for invalid cases (e.g. 
complex or decimal floating-point argument passed without a corresponding 
function available) than you can get from complicated macros.  If the 
return type is type-generic, an exactly matching function would be 
required; if the return type is fixed and there is no exactly matching 
function, the first function, if any, with matching radix and argument 
type with as much range and precision would be chosen (see the proposed 
resolution to CFP DR#13 at 
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2149.htm>).

There's a reasonable question of whether you want the first argument or 
whether you should have __builtin_tgmath without that argument and then 
later add __builtin_tgmath_operator for 
__STDC_TGMATH_OPERATOR_EVALUATION__ and potentially other variants - but I 
think having __builtin_tgmath, with or without such an argument, would 
clearly be better than having lots of variants like __builtin_tgpow or 
e.g. one specific to unary functions with both real and complex variants 
and another for real-only binary functions.  And it's important not to 
need extra variants just to support extra floating-point types such as 
_Float128.