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.