diff options
author | Joseph Myers <joseph@codesourcery.com> | 2023-01-06 19:31:26 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2023-01-06 19:31:26 +0000 |
commit | 5b68fb47bd24abc2e6a65e5617f586d1c1b81d4e (patch) | |
tree | d5951144716ceb901447d8ef2d4449cab1f991c3 /gcc/doc | |
parent | f3707a55acb980fbcd412ceb980b5621decb4dc0 (diff) | |
download | gcc-5b68fb47bd24abc2e6a65e5617f586d1c1b81d4e.zip gcc-5b68fb47bd24abc2e6a65e5617f586d1c1b81d4e.tar.gz gcc-5b68fb47bd24abc2e6a65e5617f586d1c1b81d4e.tar.bz2 |
c: C2x semantics for __builtin_tgmath
__builtin_tgmath implements <tgmath.h> semantics for integer generic
arguments that handle cases involving _FloatN / _FloatNx types as
specified in TS 18661-3 plus some defect fixes.
C2x has further changes to the semantics for <tgmath.h> macros with
such types, which should also be considered defect fixes (although
handled through the integration of TS 18661-3 in C2x rather than
through an issue tracking process). Specifically, the rules were
changed because of problems raised with using the macros with the
evaluation format types such as float_t and _Float32_t: the older
version of the rules didn't allow passing _FloatN / _FloatNx types to
the narrowing macros returning float or double, or passing float /
double / long double to the narrowing macros returning _FloatN /
_FloatNx, which was a problem with the evaluation format types which
could be either kind of type depending on the value of
FLT_EVAL_METHOD.
Thus the new rules allow cases of mixing types which were not allowed
before - which is not itself a problem for __builtin_tgmath - and, as
part of the changes, the handling of integer arguments was also
changed: if there is any _FloatNx generic argument, integer generic
arguments are treated as _Float32x (not double), while the rule about
treating integer arguments to narrowing macros returning _FloatN or
_FloatNx as _Float64 not double was removed (no longer needed now
double is a valid argument to such macros).
Implement the changes for __builtin_tgmath. (The changes also added a
rule that if any argument is _DecimalNx, integer arguments are treated
as _Decimal64x, but GCC doesn't support _DecimalNx types so nothing is
done about that.)
I have a corresponding glibc patch to update glibc test expectations
for C2x and also ensure that appropriate semantics are followed when
GCC 7 through 12 are used with <tgmath.h> (avoiding __builtin_tgmath
in cases where it doesn't match the C2x semantics).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
* doc/extend.texi (__builtin_tgmath): Do not restate standard rule
for handling real integer types.
gcc/c/
* c-parser.cc (c_parser_postfix_expression): Handle integer
generic arguments to functions passed to __builtin_tgmath as
_Float32x if any argument has _FloatNx or _Complex _FloatNx type.
Do not handle integer arguments to some narrowing functions as
_Float64.
gcc/testsuite/
* gcc.dg/builtin-tgmath-3.c: Update expectations and add more
tests.
Diffstat (limited to 'gcc/doc')
-rw-r--r-- | gcc/doc/extend.texi | 5 |
1 files changed, 2 insertions, 3 deletions
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 68d7760..1103e99 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -13923,9 +13923,8 @@ corresponding to @var{t} for each function. The standard rules for @code{<tgmath.h>} macros are used to find a common type @var{u} from the types of the arguments for parameters whose types vary between the functions; complex integer types (a GNU -extension) are treated like @code{_Complex double} for this purpose -(or @code{_Complex _Float64} if all the function return types are the -same @code{_Float@var{n}} or @code{_Float@var{n}x} type). +extension) are treated like the complex type corresponding to the real +floating type that would be chosen for the corresponding real integer type. If the function return types vary, or are all the same integer type, the function called is the one for which @var{t} is @var{u}, and it is an error if there is no such function. If the function return types |