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

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #7 from Joseph S. Myers  ---
Fixed for GCC 8 (given appropriate change to the tgmath.h being used to use
__builtin_tgmath).

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

[jsm28 at gcc dot gnu.org]

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

--- Comment #6 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Nov 15 01:53:45 2017
New Revision: 254749

URL: https://gcc.gnu.org/viewcvs?rev=254749=gcc=rev
Log:
Add __builtin_tgmath for better tgmath.h implementation (bug 81156).

Various implementations of C99/C11  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  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  to include  and
.

__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_ to
  cause a non-type-generic call to use the constant rounding
  direction (it seems cleaner to add a new __builtin_ 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_ 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, 

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

[equilibrium556 at gmx dot de]

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

--- Comment #5 from equilibrium556 at gmx dot de ---
I filed a bug report for glibc as well:
https://sourceware.org/bugzilla/show_bug.cgi?id=21660

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

[joseph at codesourcery dot com]

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

--- Comment #4 from 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 
).

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.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-22
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
A workaround is to split the expression and use temporaries -- with the
disadvantage of needing to spell out the intermediate type explicitely.

Not sure how we'd do __builtin_tgmath but I know how we'd do __builtin_tgpow,
etc.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Richard Biener  ---
Looks like GCC enhancement and quite severe glibc bug -> please file a bug for
glibc at sourceware.org.

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

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Different OSes (and sometimes different compilers) have different tgmath.h 
implementations.  Those implementations typically expand calls to tgmath.h 
macros to expansions that repeat their arguments many times.

You have sqrt(pow(sqrt(pow(.  In glibc's tgmath.h, pow expands to 
repeat each of its arguments 58 times, and sqrt repeats each of its 
arguments 57 times.  So you have 58*57*58*57 = 10929636 repetitions of 
each of the arguments to each of the inner pow calls, even before 
accounting for all of the other text in there, and all those tokens need 
to be generated and parsed even though most of it ends up getting folded 
away eventually.  I expect in principle your code could compile given 
enough memory and time, but "enough" might be very large.

Maybe I should implement __builtin_tgmath to allow macros that expand each 
argument once only, which is clearly best for such macros to allow deeply 
nested calls.  (My inclination is to prefer a smart __builtin_tgmath that 
can be used for all tgmath.h macros, instead of several dumber variants 
such as I previously suggested in projects/c-frontend.html; it would be 
desirable for it to be able to handle TS 18661-1 functions that round 
result to narrower type and TS 18661-3 types as well.  Such builtins would 
probably be necessary for implementing TS 18661-5 
__STDC_TGMATH_OPERATOR_EVALUATION__.)