Re: Add __builtin_tgmath for better tgmath.h implementation (bug 81156)
On Wed, 15 Nov 2017, Richard Biener wrote: > Thanks - I suppose we can't avoid the repeated expansion by sth like > > #define exp(Val) ({ __typeof__ Val tem = Val; __TGMATH_UNARY_REAL_IMAG > (tem, exp, cexp); }) Well, that still expands its argument twice. You'd need to use __auto_type to avoid the double expansion. And then you'd still have extremely complicated expansions (that are correspondingly unfriendly if a user makes a mistake with a call, e.g. an argument of unsupported type), and complications around getting the right semantics when decimal floating point is involved. And use of ({ }) doesn't work in sizeof outside functions. And that wouldn't help with cases such as __STDC_TGMATH_OPERATOR_EVALUATION__, whereas it would actually be easy to add __builtin_tgmath_operator that's handled the same as __builtin_tgmath but ends up calling a function based on evaluation formats and producing an EXCESS_PRECISION_EXPR. (Clang overloadable functions in C don't avoid the multiple expansion either, or at least Clang's tgmath.h doesn't.) -- Joseph S. Myers jos...@codesourcery.com
Re: Add __builtin_tgmath for better tgmath.h implementation (bug 81156)
On Wed, Nov 15, 2017 at 2:54 AM, Joseph Myerswrote: > 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. Applied to > mainline. Thanks - I suppose we can't avoid the repeated expansion by sth like #define exp(Val) ({ __typeof__ Val tem = Val; __TGMATH_UNARY_REAL_IMAG (tem, exp, cexp); }) ? Richard. > gcc: > 2017-11-15 Joseph Myers > > PR c/81156 > * 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) >
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. Applied to mainline. gcc: 2017-11-15 Joseph MyersPR c/81156 * 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: 2017-11-15 Joseph Myers PR c/81156 * c-parser.c