This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/81156] GCC fails to compile a formula with tgmath.h
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 22 Jun 2017 13:47:38 +0000
- Subject: [Bug c/81156] GCC fails to compile a formula with tgmath.h
- Auto-submitted: auto-generated
- References: <bug-81156-4@http.gcc.gnu.org/bugzilla/>
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.