* [PATCH 0/12] GCC _BitInt support [PR102989]
@ 2023-08-09 18:14 Jakub Jelinek
2023-08-09 21:17 ` Joseph Myers
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Jakub Jelinek @ 2023-08-09 18:14 UTC (permalink / raw)
To: Richard Biener, Joseph S. Myers, Uros Bizjak, hjl.tools; +Cc: gcc-patches
Hi!
The following patch series introduces support for C23 bit-precise integer
types. In short, they are similar to other integral types in many ways,
just aren't subject for integral promotions if smaller than int and they can
have even much wider precisions than ordinary integer types.
This series includes and thus subsumes all so far uncommitted _BitInt related
patches. Compared to the last posted series, there is bit-field _BitInt
support, _Atomic/stdatomic.h support, conversions between _Decimal{32,64,128}
and _BitInt and vice versa (this particular item compared to what has been
posted before has a fix for the large powers of 10 computations which
with the _BitInt(575) limitation can't be really seen so far, but I've tried
to call the underlying routines with very large arrays of limbs, and in
addition to that the generated tables header has been made more compact) and
Richard's patch review feedback has been incorporated and series has been
further split into more patches.
It is enabled only on targets which have agreed on processor specific
ABI how to lay those out or pass as function arguments/return values,
which currently is just x86-64 I believe, would be nice if target maintainers
helped to get agreement on psABI changes and GCC 14 could enable it on far
more architectures than just one.
C23 says that <limits.h> defines BITINT_MAXWIDTH macro and that is the
largest supported precision of the _BitInt types, smallest is precision
of unsigned long long (but due to lack of psABI agreement we'll violate
that on architectures which don't have the support done yet).
The following series uses for the time just WIDE_INT_MAX_PRECISION as
that BITINT_MAXWIDTH, with the intent to increase it incrementally later
on. WIDE_INT_MAX_PRECISION is 575 bits on x86_64, but will be even smaller
on lots of architectures. This is the largest precision we can support
without changes of wide_int/widest_int representation (to make those non-POD
and allow use of some allocated buffer rather than the included fixed size
one). Once that would be overcome, there is another internal enforced limit,
INTEGER_CST in current layout allows at most 255 64-bit limbs, which is
16320 bits as another cap. And if that is overcome, then we have limitation
of TYPE_PRECISION being 16-bit, so 65535 as maximum precision. Perhaps
we could make TYPE_PRECISION dependent on BITINT_TYPE vs. others and use
32-bit precision in that case later. Latest Clang/LLVM I think supports
on paper up to 8388608 bits, but is hardly usable even with much shorter
precisions.
Besides this hopefully temporary cap on supported precision and support
only on targets which buy into it, the support has the following limitations:
- _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs
mention how those should be passed/returned; in a limited way they are
supported internally because the internal functions into which
__builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a
hack to return 2 values without using references/pointers
- vectors of _BitInt(N) aren't supported, both because psABIs don't specify
how that works and because I'm not really sure it would be useful given
lack of hw support for anything but bit-precise integers with the same
bit precision as standard integer types
Because the bit-precise types have different behavior both in the C FE
(e.g. the lack of promotion) and do or can have different behavior in type
layout and function argument passing/returning values, the patch introduces
a new integral type, BITINT_TYPE, so various spots which explicitly check
for INTEGER_TYPE and not say INTEGRAL_TYPE_P macro need to be adjusted.
Also the assumption that all integral types have scalar integer type mode
is no longer true, larger BITINT_TYPEs have BLKmode type.
The patch makes 4 different categories of _BitInt depending on the target hook
decisions and their precision. The x86-64 psABI says that _BitInt which fit
into signed/unsigned char, short, int, long and long long are laid out and
passed as those types (with padding bits undefined if they don't have mode
precision). Such smallest precision bit-precise integer types are categorized
as small, the target hook gives for specific precision a scalar integral mode
where a single such mode contains all the bits. Such small _BitInt types are
generally kept in the IL until expansion into RTL, with minor tweaks during
expansion to avoid relying on the padding bit values. All larger precision
_BitInt types are supposed to be handled as structure containing an array
of limbs or so, where a limb has some integral mode (for libgcc purposes
best if it has word-size) and the limbs have either little or big endian
ordering in the array. The padding bits in the most significant limb if any
are either undefined or should be always sign/zero extended (but support for this
isn't in yet, we don't know if any psABI will require it). As mentioned in
some psABI proposals, while currently there is just one limb mode, if the limb
ordering would follow normal target endianity, there is always a possibility
to have two limb modes, one used for ABI purposes (in alignment/size decisions)
and another one used during the actual lowering or libgcc helpers.
The second _BitInt category is called medium in the series, those are _BitInt
precisions which need more than one limb, but the precision is still smaller
than TImode precision (or DImode on targets which don't support __int128).
Most arithmetics on such types can be lowered simply to casts to the larger/equal
precision {,unsigned} {long long,__int128} type and performing the arith on
normal integers and then casted back. Larger _BitInt precision typically
will have BLKmode and will be lowered in a new bitintlower* pass right after
complex lowering (for -O1+ it is shortly after IPA) into series of operations
on individual limbs. The series talks about large and huge _BitInts,
large ones are up to one bit smaller than 4 limbs and are lowered in most
places in straight line code iterating of the limbs and huge ones are those
which use some loop to handle most of the limbs and only handle up to 2 limbs
before or after the loop.
Most operations, like bitwise operations, addition, subtraction, left shift by
constant smaller than limb precision, some casts, ==/!= comparisons,
loads/stores are handled in a loop with 2 limbs per iteration followed by 0, 1
or 2 limbs handled after, are called in the series mergeable and the loop
handles perhaps many different operations with single use in the same bb.
>/>=/</<= comparisons are handled optionally together with operand casts and
loads in one optional straight line handling of most significant limb (unless
unsigned and precision is multiple of limb precision) followed by a loop handling
one limb at a time from more significant down to least significant.
Other operations like arbitrary left shifts or all right shifts are handled also
in a loop doing one limb at a time but accessing possibly some other limb.
Multiplication, division, modulo and floating point to/from _BitInt conversions
are handled using libgcc library routines.
__builtin_{add,sub}_overflow are handled similarly to addition/subtraction but
not mergeable with anything except implicit or explicit casts/loads and with
tracking carry at the end.
__builtin_mul_overflow is implemented by using infinite precision library
multiplication (from range info we determine ranges of operands and use possibly
a temporary array to hold large enough result) and then comparing if all bits
are zero resp. sign bit copies.
The libgcc library routines, both for multiplication, division, modulo or
conversions with floating point use a special calling convention, where for each
_BitInt a pointer to array of limbs and precision are passed. The precision
is signed SImode, if positive, it is a known minimum precision in bits of an
unsigned operand, if it is negative, its absolute value is known minimum
precision in bits of a signed operand. That way, the compiler using e.g. range
information can already pre-reduce precision and at runtime libgcc can reduce
it further by skipping over most significant limbs which contain just zeros or
sign bit copies. In any case, small _BitInt types can be passed differently,
but for passing those to the libgcc routines they need to be forced into
an array of limbs as well (typically just one or two limbs).
The whole series have been successfully bootstrapped/regtested on x86_64-linux
and i686-linux.
Jakub Jelinek (12):
expr: Small optimization [PR102989]
lto-streamer-in: Adjust assert [PR102989]
phiopt: Fix phiopt ICE on vops [PR102989]
Middle-end _BitInt support [PR102989]
_BitInt lowering support [PR102989]
i386: Enable _BitInt on x86-64 [PR102989]
ubsan: _BitInt -fsanitize=undefined support [PR102989]
libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989]
libgcc _BitInt support [PR102989]
C _BitInt support [PR102989]
testsuite part 1 for _BitInt support [PR102989]
testsuite part 2 for _BitInt support [PR102989]
gcc/Makefile.in | 1
gcc/builtins.cc | 7
gcc/c-family/c-common.cc | 261
gcc/c-family/c-common.h | 2
gcc/c-family/c-cppbuiltin.cc | 23
gcc/c-family/c-lex.cc | 164
gcc/c-family/c-pretty-print.cc | 32
gcc/c-family/c-ubsan.cc | 4
gcc/c/c-convert.cc | 1
gcc/c/c-decl.cc | 194
gcc/c/c-parser.cc | 27
gcc/c/c-tree.h | 18
gcc/c/c-typeck.cc | 132
gcc/cfgexpand.cc | 4
gcc/config/i386/i386.cc | 33
gcc/convert.cc | 8
gcc/doc/generic.texi | 9
gcc/doc/tm.texi | 15
gcc/doc/tm.texi.in | 2
gcc/dwarf2out.cc | 43
gcc/expr.cc | 71
gcc/fold-const.cc | 75
gcc/gimple-expr.cc | 9
gcc/gimple-fold.cc | 82
gcc/gimple-lower-bitint.cc | 6074 +++++++++++++++++++++++
gcc/gimple-lower-bitint.h | 31
gcc/glimits.h | 5
gcc/internal-fn.cc | 145
gcc/internal-fn.def | 6
gcc/internal-fn.h | 4
gcc/lto-streamer-in.cc | 2
gcc/match.pd | 1
gcc/passes.def | 3
gcc/pretty-print.h | 19
gcc/stor-layout.cc | 86
gcc/target.def | 19
gcc/target.h | 14
gcc/targhooks.cc | 8
gcc/targhooks.h | 1
gcc/testsuite/gcc.dg/atomic/stdatomic-bitint-1.c | 442 +
gcc/testsuite/gcc.dg/atomic/stdatomic-bitint-2.c | 450 +
gcc/testsuite/gcc.dg/bitint-1.c | 26
gcc/testsuite/gcc.dg/bitint-10.c | 15
gcc/testsuite/gcc.dg/bitint-11.c | 9
gcc/testsuite/gcc.dg/bitint-12.c | 31
gcc/testsuite/gcc.dg/bitint-13.c | 17
gcc/testsuite/gcc.dg/bitint-14.c | 11
gcc/testsuite/gcc.dg/bitint-15.c | 10
gcc/testsuite/gcc.dg/bitint-16.c | 31
gcc/testsuite/gcc.dg/bitint-17.c | 47
gcc/testsuite/gcc.dg/bitint-18.c | 44
gcc/testsuite/gcc.dg/bitint-2.c | 116
gcc/testsuite/gcc.dg/bitint-3.c | 40
gcc/testsuite/gcc.dg/bitint-4.c | 39
gcc/testsuite/gcc.dg/bitint-5.c | 63
gcc/testsuite/gcc.dg/bitint-6.c | 15
gcc/testsuite/gcc.dg/bitint-7.c | 16
gcc/testsuite/gcc.dg/bitint-8.c | 34
gcc/testsuite/gcc.dg/bitint-9.c | 52
gcc/testsuite/gcc.dg/dfp/bitint-1.c | 98
gcc/testsuite/gcc.dg/dfp/bitint-2.c | 91
gcc/testsuite/gcc.dg/dfp/bitint-3.c | 98
gcc/testsuite/gcc.dg/dfp/bitint-4.c | 156
gcc/testsuite/gcc.dg/dfp/bitint-5.c | 159
gcc/testsuite/gcc.dg/dfp/bitint-6.c | 156
gcc/testsuite/gcc.dg/torture/bitint-1.c | 114
gcc/testsuite/gcc.dg/torture/bitint-10.c | 38
gcc/testsuite/gcc.dg/torture/bitint-11.c | 77
gcc/testsuite/gcc.dg/torture/bitint-12.c | 128
gcc/testsuite/gcc.dg/torture/bitint-13.c | 171
gcc/testsuite/gcc.dg/torture/bitint-14.c | 140
gcc/testsuite/gcc.dg/torture/bitint-15.c | 264
gcc/testsuite/gcc.dg/torture/bitint-16.c | 385 +
gcc/testsuite/gcc.dg/torture/bitint-17.c | 82
gcc/testsuite/gcc.dg/torture/bitint-18.c | 117
gcc/testsuite/gcc.dg/torture/bitint-19.c | 190
gcc/testsuite/gcc.dg/torture/bitint-2.c | 118
gcc/testsuite/gcc.dg/torture/bitint-20.c | 190
gcc/testsuite/gcc.dg/torture/bitint-21.c | 282 +
gcc/testsuite/gcc.dg/torture/bitint-22.c | 282 +
gcc/testsuite/gcc.dg/torture/bitint-23.c | 804 +++
gcc/testsuite/gcc.dg/torture/bitint-24.c | 804 +++
gcc/testsuite/gcc.dg/torture/bitint-25.c | 91
gcc/testsuite/gcc.dg/torture/bitint-26.c | 66
gcc/testsuite/gcc.dg/torture/bitint-27.c | 373 +
gcc/testsuite/gcc.dg/torture/bitint-28.c | 20
gcc/testsuite/gcc.dg/torture/bitint-29.c | 24
gcc/testsuite/gcc.dg/torture/bitint-3.c | 134
gcc/testsuite/gcc.dg/torture/bitint-30.c | 19
gcc/testsuite/gcc.dg/torture/bitint-31.c | 23
gcc/testsuite/gcc.dg/torture/bitint-32.c | 24
gcc/testsuite/gcc.dg/torture/bitint-33.c | 24
gcc/testsuite/gcc.dg/torture/bitint-34.c | 24
gcc/testsuite/gcc.dg/torture/bitint-35.c | 23
gcc/testsuite/gcc.dg/torture/bitint-36.c | 23
gcc/testsuite/gcc.dg/torture/bitint-37.c | 23
gcc/testsuite/gcc.dg/torture/bitint-38.c | 56
gcc/testsuite/gcc.dg/torture/bitint-39.c | 57
gcc/testsuite/gcc.dg/torture/bitint-4.c | 134
gcc/testsuite/gcc.dg/torture/bitint-40.c | 40
gcc/testsuite/gcc.dg/torture/bitint-41.c | 34
gcc/testsuite/gcc.dg/torture/bitint-42.c | 184
gcc/testsuite/gcc.dg/torture/bitint-5.c | 359 +
gcc/testsuite/gcc.dg/torture/bitint-6.c | 359 +
gcc/testsuite/gcc.dg/torture/bitint-7.c | 386 +
gcc/testsuite/gcc.dg/torture/bitint-8.c | 391 +
gcc/testsuite/gcc.dg/torture/bitint-9.c | 391 +
gcc/testsuite/gcc.dg/ubsan/bitint-1.c | 49
gcc/testsuite/gcc.dg/ubsan/bitint-2.c | 49
gcc/testsuite/gcc.dg/ubsan/bitint-3.c | 45
gcc/testsuite/lib/target-supports.exp | 27
gcc/tree-pass.h | 3
gcc/tree-pretty-print.cc | 23
gcc/tree-ssa-coalesce.cc | 148
gcc/tree-ssa-live.cc | 8
gcc/tree-ssa-live.h | 8
gcc/tree-ssa-phiopt.cc | 1
gcc/tree-ssa-sccvn.cc | 11
gcc/tree-switch-conversion.cc | 71
gcc/tree.cc | 67
gcc/tree.def | 9
gcc/tree.h | 94
gcc/typeclass.h | 3
gcc/ubsan.cc | 89
gcc/ubsan.h | 3
gcc/varasm.cc | 55
gcc/vr-values.cc | 27
libcpp/expr.cc | 29
libcpp/include/cpplib.h | 1
libgcc/Makefile.in | 5
libgcc/config/aarch64/t-softfp | 2
libgcc/config/i386/64/t-softfp | 2
libgcc/config/i386/libgcc-glibc.ver | 10
libgcc/config/i386/t-softfp | 5
libgcc/config/riscv/t-softfp32 | 6
libgcc/config/rs6000/t-e500v1-fp | 2
libgcc/config/rs6000/t-e500v2-fp | 2
libgcc/config/t-softfp | 12
libgcc/config/t-softfp-sfdftf | 1
libgcc/config/t-softfp-tf | 1
libgcc/libgcc-std.ver.in | 10
libgcc/libgcc2.c | 681 ++
libgcc/libgcc2.h | 15
libgcc/soft-fp/bitint.h | 329 +
libgcc/soft-fp/bitintpow10.c | 132
libgcc/soft-fp/bitintpow10.h | 4947 ++++++++++++++++++
libgcc/soft-fp/fixddbitint.c | 205
libgcc/soft-fp/fixdfbitint.c | 71
libgcc/soft-fp/fixsdbitint.c | 196
libgcc/soft-fp/fixsfbitint.c | 71
libgcc/soft-fp/fixtdbitint.c | 242
libgcc/soft-fp/fixtfbitint.c | 81
libgcc/soft-fp/fixxfbitint.c | 82
libgcc/soft-fp/floatbitintbf.c | 59
libgcc/soft-fp/floatbitintdd.c | 264
libgcc/soft-fp/floatbitintdf.c | 64
libgcc/soft-fp/floatbitinthf.c | 59
libgcc/soft-fp/floatbitintsd.c | 235
libgcc/soft-fp/floatbitintsf.c | 59
libgcc/soft-fp/floatbitinttd.c | 271 +
libgcc/soft-fp/floatbitinttf.c | 73
libgcc/soft-fp/floatbitintxf.c | 74
libgcc/soft-fp/op-common.h | 31
163 files changed, 26268 insertions(+), 220 deletions(-)
Jakub
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-09 18:14 [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek @ 2023-08-09 21:17 ` Joseph Myers 2023-08-10 6:55 ` Richard Biener 2023-08-10 10:10 ` [PATCH 13/12] C _BitInt incremental fixes [PR102989] Jakub Jelinek 2023-08-21 15:24 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek 2023-09-18 11:39 ` Matthew Malcomson 2 siblings, 2 replies; 17+ messages in thread From: Joseph Myers @ 2023-08-09 21:17 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Biener, Uros Bizjak, hjl.tools, gcc-patches On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > mention how those should be passed/returned; in a limited way they are > supported internally because the internal functions into which > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > hack to return 2 values without using references/pointers What happens when the usual arithmetic conversions are applied to operands, one of which is a complex integer type and the other of which is a wider _BitInt type? I don't see anything in the code to disallow this case (which would produce an expression with a _Complex _BitInt type), or any testcases for it. Other testcases I think should be present (along with any corresponding changes needed to the code itself): * Verifying that the new integer constant suffix is rejected for C++. * Verifying appropriate pedwarn-if-pedantic for the new constant suffix for versions of C before C2x (and probably for use of _BitInt type specifiers before C2x as well) - along with the expected -Wc11-c2x-compat handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-09 21:17 ` Joseph Myers @ 2023-08-10 6:55 ` Richard Biener 2023-08-10 7:12 ` Jakub Jelinek 2023-08-10 10:10 ` [PATCH 13/12] C _BitInt incremental fixes [PR102989] Jakub Jelinek 1 sibling, 1 reply; 17+ messages in thread From: Richard Biener @ 2023-08-10 6:55 UTC (permalink / raw) To: Joseph Myers; +Cc: Jakub Jelinek, Uros Bizjak, hjl.tools, gcc-patches On Wed, 9 Aug 2023, Joseph Myers wrote: > On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > > > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > > mention how those should be passed/returned; in a limited way they are > > supported internally because the internal functions into which > > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > > hack to return 2 values without using references/pointers > > What happens when the usual arithmetic conversions are applied to > operands, one of which is a complex integer type and the other of which is > a wider _BitInt type? I don't see anything in the code to disallow this > case (which would produce an expression with a _Complex _BitInt type), or > any testcases for it. > > Other testcases I think should be present (along with any corresponding > changes needed to the code itself): > > * Verifying that the new integer constant suffix is rejected for C++. > > * Verifying appropriate pedwarn-if-pedantic for the new constant suffix > for versions of C before C2x (and probably for use of _BitInt type > specifiers before C2x as well) - along with the expected -Wc11-c2x-compat > handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. Can we go as far as deprecating our _Complex int extension for C17 and make it unavailable for C2x, side-stepping the issue? Or maybe at least considering that for C2x? Richard. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-10 6:55 ` Richard Biener @ 2023-08-10 7:12 ` Jakub Jelinek 2023-08-10 7:26 ` Andrew Pinski 0 siblings, 1 reply; 17+ messages in thread From: Jakub Jelinek @ 2023-08-10 7:12 UTC (permalink / raw) To: Richard Biener; +Cc: Joseph Myers, Uros Bizjak, hjl.tools, gcc-patches On Thu, Aug 10, 2023 at 06:55:05AM +0000, Richard Biener wrote: > On Wed, 9 Aug 2023, Joseph Myers wrote: > > > On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > > > > > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > > > mention how those should be passed/returned; in a limited way they are > > > supported internally because the internal functions into which > > > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > > > hack to return 2 values without using references/pointers > > > > What happens when the usual arithmetic conversions are applied to > > operands, one of which is a complex integer type and the other of which is > > a wider _BitInt type? I don't see anything in the code to disallow this > > case (which would produce an expression with a _Complex _BitInt type), or > > any testcases for it. > > > > Other testcases I think should be present (along with any corresponding > > changes needed to the code itself): > > > > * Verifying that the new integer constant suffix is rejected for C++. > > > > * Verifying appropriate pedwarn-if-pedantic for the new constant suffix > > for versions of C before C2x (and probably for use of _BitInt type > > specifiers before C2x as well) - along with the expected -Wc11-c2x-compat > > handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. > > Can we go as far as deprecating our _Complex int extension for > C17 and make it unavailable for C2x, side-stepping the issue? > Or maybe at least considering that for C2x? I can just sorry at it for now. And now that I search through the x86-64 psABI again, it doesn't mention complex integers at all, so we are there on our own. And it seems we don't have anything for complex integers on the library side and the complex lowering is before bitint lowering, so it might just work with < 10 lines of changes in code + testsuite, but if we do enable it, let's do it incrementally. Jakub ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-10 7:12 ` Jakub Jelinek @ 2023-08-10 7:26 ` Andrew Pinski 0 siblings, 0 replies; 17+ messages in thread From: Andrew Pinski @ 2023-08-10 7:26 UTC (permalink / raw) To: Jakub Jelinek Cc: Richard Biener, Joseph Myers, Uros Bizjak, hjl.tools, gcc-patches On Thu, Aug 10, 2023 at 12:13 AM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Thu, Aug 10, 2023 at 06:55:05AM +0000, Richard Biener wrote: > > On Wed, 9 Aug 2023, Joseph Myers wrote: > > > > > On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > > > > > > > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > > > > mention how those should be passed/returned; in a limited way they are > > > > supported internally because the internal functions into which > > > > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > > > > hack to return 2 values without using references/pointers > > > > > > What happens when the usual arithmetic conversions are applied to > > > operands, one of which is a complex integer type and the other of which is > > > a wider _BitInt type? I don't see anything in the code to disallow this > > > case (which would produce an expression with a _Complex _BitInt type), or > > > any testcases for it. > > > > > > Other testcases I think should be present (along with any corresponding > > > changes needed to the code itself): > > > > > > * Verifying that the new integer constant suffix is rejected for C++. > > > > > > * Verifying appropriate pedwarn-if-pedantic for the new constant suffix > > > for versions of C before C2x (and probably for use of _BitInt type > > > specifiers before C2x as well) - along with the expected -Wc11-c2x-compat > > > handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. > > > > Can we go as far as deprecating our _Complex int extension for > > C17 and make it unavailable for C2x, side-stepping the issue? > > Or maybe at least considering that for C2x? > > I can just sorry at it for now. And now that I search through the x86-64 > psABI again, it doesn't mention complex integers at all, so we are there on > our own. And it seems we don't have anything for complex integers on the > library side and the complex lowering is before bitint lowering, so it might > just work with < 10 lines of changes in code + testsuite, but if we do > enable it, let's do it incrementally. _Complex int division also has issues which is another reason to deprecate/remove it; see PR 104937 for that and https://gcc.gnu.org/legacy-ml/gcc/2001-11/msg00790.html (which was the first time to deprecate _Complex int; https://gcc.gnu.org/legacy-ml/gcc/2001-11/msg00863.html). Thanks, Andrew > > Jakub > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 13/12] C _BitInt incremental fixes [PR102989] 2023-08-09 21:17 ` Joseph Myers 2023-08-10 6:55 ` Richard Biener @ 2023-08-10 10:10 ` Jakub Jelinek 2023-08-10 15:22 ` [PATCH 13/12 v2] " Jakub Jelinek 1 sibling, 1 reply; 17+ messages in thread From: Jakub Jelinek @ 2023-08-10 10:10 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc-patches On Wed, Aug 09, 2023 at 09:17:57PM +0000, Joseph Myers wrote: > > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > > mention how those should be passed/returned; in a limited way they are > > supported internally because the internal functions into which > > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > > hack to return 2 values without using references/pointers > > What happens when the usual arithmetic conversions are applied to > operands, one of which is a complex integer type and the other of which is > a wider _BitInt type? I don't see anything in the code to disallow this > case (which would produce an expression with a _Complex _BitInt type), or > any testcases for it. I've added a sorry for that case (+ return the narrower COMPLEX_TYPE). Also added testcase to verify we don't create VECTOR_TYPEs of BITINT_TYPE even if they have mode precision and suitable size (others were rejected already before). > Other testcases I think should be present (along with any corresponding > changes needed to the code itself): > > * Verifying that the new integer constant suffix is rejected for C++. Done. > * Verifying appropriate pedwarn-if-pedantic for the new constant suffix > for versions of C before C2x (and probably for use of _BitInt type > specifiers before C2x as well) - along with the expected -Wc11-c2x-compat > handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. Done. Here is an incremental patch which does that: 2023-08-10 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/c/ * c-decl.cc (finish_declspecs): Emit pedwarn_c11 on _BitInt. * c-typeck.cc (c_common_type): Emit sorry for common type between _Complex integer and larger _BitInt and return the _Complex integer. gcc/c-family/ * c-attribs.cc (type_valid_for_vector_size): Reject vector types with BITINT_TYPE elements even if they have mode precision and suitable size. gcc/testsuite/ * gcc.dg/bitint-19.c: New test. * gcc.dg/bitint-20.c: New test. * gcc.dg/bitint-21.c: New test. * gcc.dg/bitint-22.c: New test. * gcc.dg/bitint-23.c: New test. * gcc.dg/bitint-24.c: New test. * gcc.dg/bitint-25.c: New test. * gcc.dg/bitint-26.c: New test. * gcc.dg/bitint-27.c: New test. * g++.dg/ext/bitint1.C: New test. * g++.dg/ext/bitint2.C: New test. * g++.dg/ext/bitint3.C: New test. * g++.dg/ext/bitint4.C: New test. libcpp/ * expr.cc (cpp_classify_number): Diagnose wb literal suffixes for -pedantic* before C2X or -Wc11-c2x-compat. --- gcc/c/c-decl.cc.jj 2023-08-10 09:26:39.776509713 +0200 +++ gcc/c/c-decl.cc 2023-08-10 11:14:12.686238299 +0200 @@ -12933,8 +12933,15 @@ finish_declspecs (struct c_declspecs *sp if (specs->u.bitint_prec == -1) specs->type = integer_type_node; else - specs->type = build_bitint_type (specs->u.bitint_prec, - specs->unsigned_p); + { + pedwarn_c11 (specs->locations[cdw_typespec], OPT_Wpedantic, + "ISO C does not support %<%s_BitInt(%d)%> before C2X", + specs->unsigned_p ? "unsigned " + : specs->signed_p ? "signed " : "", + specs->u.bitint_prec); + specs->type = build_bitint_type (specs->u.bitint_prec, + specs->unsigned_p); + } break; default: gcc_unreachable (); --- gcc/c/c-typeck.cc.jj 2023-08-10 09:26:39.781509641 +0200 +++ gcc/c/c-typeck.cc 2023-08-10 10:03:00.722917789 +0200 @@ -819,6 +819,12 @@ c_common_type (tree t1, tree t2) return t1; else if (code2 == COMPLEX_TYPE && TREE_TYPE (t2) == subtype) return t2; + else if (TREE_CODE (subtype) == BITINT_TYPE) + { + sorry ("%<_Complex _BitInt(%d)%> unsupported", + TYPE_PRECISION (subtype)); + return code1 == COMPLEX_TYPE ? t1 : t2; + } else return build_complex_type (subtype); } --- gcc/c-family/c-attribs.cc.jj 2023-06-03 15:32:04.311412926 +0200 +++ gcc/c-family/c-attribs.cc 2023-08-10 10:07:05.222377604 +0200 @@ -4366,7 +4366,8 @@ type_valid_for_vector_size (tree type, t && GET_MODE_CLASS (orig_mode) != MODE_INT && !ALL_SCALAR_FIXED_POINT_MODE_P (orig_mode)) || !tree_fits_uhwi_p (TYPE_SIZE_UNIT (type)) - || TREE_CODE (type) == BOOLEAN_TYPE) + || TREE_CODE (type) == BOOLEAN_TYPE + || TREE_CODE (type) == BITINT_TYPE) { if (error_p) error ("invalid vector type for attribute %qE", atname); --- gcc/testsuite/gcc.dg/bitint-19.c.jj 2023-08-10 09:33:49.205287806 +0200 +++ gcc/testsuite/gcc.dg/bitint-19.c 2023-08-10 09:36:43.312765194 +0200 @@ -0,0 +1,16 @@ +/* PR c/102989 */ +/* { dg-do compile { target bitint } } */ +/* { dg-options "-std=gnu2x" } */ + +#define expr_has_type(e, t) _Generic (e, default : 0, t : 1) + +void +foo (_Complex int ci, _Complex long long cl) +{ + _BitInt(__SIZEOF_INT__ * __CHAR_BIT__ - 1) bi = 0wb; + _BitInt(__SIZEOF_LONG_LONG__ * __CHAR_BIT__ - 1) bl = 0wb; + static_assert (expr_has_type (ci + bi, _Complex int)); + static_assert (expr_has_type (cl + bl, _Complex long long)); + static_assert (expr_has_type (bi + ci, _Complex int)); + static_assert (expr_has_type (bl + cl, _Complex long long)); +} --- gcc/testsuite/gcc.dg/bitint-20.c.jj 2023-08-10 09:40:14.340707650 +0200 +++ gcc/testsuite/gcc.dg/bitint-20.c 2023-08-10 10:04:35.306548279 +0200 @@ -0,0 +1,16 @@ +/* PR c/102989 */ +/* { dg-do compile { target bitint } } */ +/* { dg-options "-std=gnu2x" } */ + +void +foo (_Complex int ci, _Complex long long cl) +{ + _BitInt(__SIZEOF_INT__ * __CHAR_BIT__ + 1) bi = 0wb; + ci + bi; /* { dg-message "unsupported" } */ + bi + ci; /* { dg-message "unsupported" } */ +#if __BITINT_MAXWIDTH__ >= 575 + _BitInt(575) bw = 0wb; + cl + bw; /* { dg-message "unsupported" "" { target bitint575 } } */ + bw + cl; /* { dg-message "unsupported" "" { target bitint575 } } */ +#endif +} --- gcc/testsuite/gcc.dg/bitint-21.c.jj 2023-08-10 10:07:31.393998652 +0200 +++ gcc/testsuite/gcc.dg/bitint-21.c 2023-08-10 10:14:14.303164800 +0200 @@ -0,0 +1,11 @@ +/* PR c/102989 */ +/* { dg-do compile { target bitint } } */ +/* { dg-options "-std=gnu2x" } */ + +#define IB __SIZEOF_INT__ * __CHAR_BIT__ +typedef _BitInt(IB) V1 __attribute__((vector_size (sizeof (_BitInt(IB))))); /* { dg-error "invalid vector type for attribute 'vector_size'" } */ +typedef _BitInt(IB) V2 __attribute__((vector_size (8 * sizeof (_BitInt(IB))))); /* { dg-error "invalid vector type for attribute 'vector_size'" } */ +#if __BITINT_MAXWIDTH__ >= 575 +typedef _BitInt(575) V3 __attribute__((vector_size (sizeof (_BitInt(575))))); /* { dg-error "invalid vector type for attribute 'vector_size'" "" { target bitint575 } } */ +typedef _BitInt(575) V3 __attribute__((vector_size (16 * sizeof (_BitInt(575))))); /* { dg-error "invalid vector type for attribute 'vector_size'" "" { target bitint575 } } */ +#endif --- gcc/testsuite/gcc.dg/bitint-22.c.jj 2023-08-10 11:51:51.975802981 +0200 +++ gcc/testsuite/gcc.dg/bitint-22.c 2023-08-10 11:52:16.923446548 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "-std=c2x -pedantic-errors" } + +_BitInt(63) a; +signed _BitInt(15) b; +unsigned _BitInt(31) c; +int d = 21wb; +long long e = 60594869054uwb; +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 +#endif +#if 0uwb == 0 +#endif --- gcc/testsuite/gcc.dg/bitint-23.c.jj 2023-08-10 11:52:29.611265273 +0200 +++ gcc/testsuite/gcc.dg/bitint-23.c 2023-08-10 11:55:03.702063742 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "-std=c2x -pedantic-errors -Wc11-c2x-compat" } + +_BitInt(63) a; /* { dg-warning "ISO C does not support '_BitInt\\\(63\\\)' before C2X" } */ +signed _BitInt(15) b; /* { dg-warning "ISO C does not support 'signed _BitInt\\\(15\\\)' before C2X" } */ +unsigned _BitInt(31) c; /* { dg-warning "ISO C does not support 'unsigned _BitInt\\\(31\\\)' before C2X" } */ +int d = 21wb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +long long e = 60594869054uwb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif +#if 0uwb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif --- gcc/testsuite/gcc.dg/bitint-24.c.jj 2023-08-10 11:56:03.403210774 +0200 +++ gcc/testsuite/gcc.dg/bitint-24.c 2023-08-10 11:56:13.037073138 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "-std=c11" } + +_BitInt(63) a; +signed _BitInt(15) b; +unsigned _BitInt(31) c; +int d = 21wb; +long long e = 60594869054uwb; +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 +#endif +#if 0uwb == 0 +#endif --- gcc/testsuite/gcc.dg/bitint-25.c.jj 2023-08-10 11:56:21.499952227 +0200 +++ gcc/testsuite/gcc.dg/bitint-25.c 2023-08-10 11:56:36.468738364 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "-std=c11 -Wno-c11-c2x-compat -pedantic-errors" } + +_BitInt(63) a; +signed _BitInt(15) b; +unsigned _BitInt(31) c; +int d = 21wb; +long long e = 60594869054uwb; +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 +#endif +#if 0uwb == 0 +#endif --- gcc/testsuite/gcc.dg/bitint-26.c.jj 2023-08-10 11:56:56.423453266 +0200 +++ gcc/testsuite/gcc.dg/bitint-26.c 2023-08-10 11:57:41.335811588 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "-std=c11 -pedantic" } + +_BitInt(63) a; /* { dg-warning "ISO C does not support '_BitInt\\\(63\\\)' before C2X" } */ +signed _BitInt(15) b; /* { dg-warning "ISO C does not support 'signed _BitInt\\\(15\\\)' before C2X" } */ +unsigned _BitInt(31) c; /* { dg-warning "ISO C does not support 'unsigned _BitInt\\\(31\\\)' before C2X" } */ +int d = 21wb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +long long e = 60594869054uwb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif +#if 0uwb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif --- gcc/testsuite/gcc.dg/bitint-27.c.jj 2023-08-10 11:57:23.690063697 +0200 +++ gcc/testsuite/gcc.dg/bitint-27.c 2023-08-10 11:57:57.352582755 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "-std=c11 -pedantic-errors" } + +_BitInt(63) a; /* { dg-error "ISO C does not support '_BitInt\\\(63\\\)' before C2X" } */ +signed _BitInt(15) b; /* { dg-error "ISO C does not support 'signed _BitInt\\\(15\\\)' before C2X" } */ +unsigned _BitInt(31) c; /* { dg-error "ISO C does not support 'unsigned _BitInt\\\(31\\\)' before C2X" } */ +int d = 21wb; /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +long long e = 60594869054uwb; /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif +#if 0uwb == 0 /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif --- gcc/testsuite/g++.dg/ext/bitint1.C.jj 2023-08-10 10:42:33.884601671 +0200 +++ gcc/testsuite/g++.dg/ext/bitint1.C 2023-08-10 10:41:44.595312345 +0200 @@ -0,0 +1,9 @@ +// PR c/102989 +// { dg-do compile } + +_BitInt(63) a; // { dg-error "expected" } +unsigned _BitInt(31) b; // { dg-error "expected" } +int c = 21wb; // { dg-error "invalid suffix \"wb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"wb'" "" { target c++11 } .-1 } +long long d = 60594869054uwb; // { dg-error "invalid suffix \"uwb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"uwb'" "" { target c++11 } .-1 } --- gcc/testsuite/g++.dg/ext/bitint2.C.jj 2023-08-10 10:42:41.950485375 +0200 +++ gcc/testsuite/g++.dg/ext/bitint2.C 2023-08-10 10:42:57.033267905 +0200 @@ -0,0 +1,10 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "" } + +_BitInt(63) a; // { dg-error "expected" } +unsigned _BitInt(31) b; // { dg-error "expected" } +int c = 21wb; // { dg-error "invalid suffix \"wb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"wb'" "" { target c++11 } .-1 } +long long d = 60594869054uwb; // { dg-error "invalid suffix \"uwb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"uwb'" "" { target c++11 } .-1 } --- gcc/testsuite/g++.dg/ext/bitint3.C.jj 2023-08-10 10:43:51.410483886 +0200 +++ gcc/testsuite/g++.dg/ext/bitint3.C 2023-08-10 10:50:06.969068962 +0200 @@ -0,0 +1,8 @@ +// PR c/102989 +// { dg-do compile { target c++11 } } + +constexpr int operator""wb (unsigned long long) { return 0; } // { dg-warning "reserved for future standardization" } +constexpr int operator""uwb (unsigned long long) { return 1; } // { dg-warning "reserved for future standardization" } + +static_assert (-42wb == 0, ""); +static_assert (81uwb == 1, ""); --- gcc/testsuite/g++.dg/ext/bitint4.C.jj 2023-08-10 10:45:20.503199319 +0200 +++ gcc/testsuite/g++.dg/ext/bitint4.C 2023-08-10 10:50:21.345861685 +0200 @@ -0,0 +1,9 @@ +// PR c/102989 +// { dg-do compile { target c++11 } } +// { dg-options "" } + +constexpr int operator""wb (unsigned long long) { return 0; } // { dg-warning "reserved for future standardization" } +constexpr int operator""uwb (unsigned long long) { return 1; } // { dg-warning "reserved for future standardization" } + +static_assert (-42wb == 0, ""); +static_assert (81uwb == 1, ""); --- libcpp/expr.cc.jj 2023-08-10 09:26:39.782509626 +0200 +++ libcpp/expr.cc 2023-08-10 11:44:29.337127064 +0200 @@ -856,6 +856,29 @@ cpp_classify_number (cpp_reader *pfile, virtual_location, 0, message); } + if ((result & CPP_N_BITINT) != 0 + && CPP_OPTION (pfile, cpp_warn_c11_c2x_compat) != 0) + { + if (CPP_OPTION (pfile, cpp_warn_c11_c2x_compat) > 0) + { + const char *message = N_("ISO C does not support literal " + "%<wb%> suffixes before C2X"); + if (CPP_PEDANTIC (pfile) && !CPP_OPTION (pfile, true_false)) + cpp_pedwarning_with_line (pfile, CPP_W_C11_C2X_COMPAT, + virtual_location, 0, message); + else + cpp_warning_with_line (pfile, CPP_W_C11_C2X_COMPAT, + virtual_location, 0, message); + } + else if (CPP_PEDANTIC (pfile) && !CPP_OPTION (pfile, true_false)) + { + const char *message = N_("ISO C does not support literal " + "%<wb%> suffixes before C2X"); + cpp_error_with_line (pfile, CPP_DL_PEDWARN, virtual_location, 0, + message); + } + } + result |= CPP_N_INTEGER; } Jakub ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 13/12 v2] C _BitInt incremental fixes [PR102989] 2023-08-10 10:10 ` [PATCH 13/12] C _BitInt incremental fixes [PR102989] Jakub Jelinek @ 2023-08-10 15:22 ` Jakub Jelinek 2023-09-05 22:26 ` Joseph Myers 0 siblings, 1 reply; 17+ messages in thread From: Jakub Jelinek @ 2023-08-10 15:22 UTC (permalink / raw) To: Joseph Myers, gcc-patches On Thu, Aug 10, 2023 at 12:10:07PM +0200, Jakub Jelinek via Gcc-patches wrote: > Here is an incremental patch which does that: Bootstrap/regtest on i686-linux (next to x86_64-linux where it went fine) revealed I forgot to add { target bitint } to dg-do compile lines. Here is an updated patch which does that and passes even on i686-linux. 2023-08-10 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/c/ * c-decl.cc (finish_declspecs): Emit pedwarn_c11 on _BitInt. * c-typeck.cc (c_common_type): Emit sorry for common type between _Complex integer and larger _BitInt and return the _Complex integer. gcc/c-family/ * c-attribs.cc (type_valid_for_vector_size): Reject vector types with BITINT_TYPE elements even if they have mode precision and suitable size. gcc/testsuite/ * gcc.dg/bitint-19.c: New test. * gcc.dg/bitint-20.c: New test. * gcc.dg/bitint-21.c: New test. * gcc.dg/bitint-22.c: New test. * gcc.dg/bitint-23.c: New test. * gcc.dg/bitint-24.c: New test. * gcc.dg/bitint-25.c: New test. * gcc.dg/bitint-26.c: New test. * gcc.dg/bitint-27.c: New test. * g++.dg/ext/bitint1.C: New test. * g++.dg/ext/bitint2.C: New test. * g++.dg/ext/bitint3.C: New test. * g++.dg/ext/bitint4.C: New test. libcpp/ * expr.cc (cpp_classify_number): Diagnose wb literal suffixes for -pedantic* before C2X or -Wc11-c2x-compat. --- gcc/c/c-decl.cc.jj 2023-08-10 09:26:39.776509713 +0200 +++ gcc/c/c-decl.cc 2023-08-10 11:14:12.686238299 +0200 @@ -12933,8 +12933,15 @@ finish_declspecs (struct c_declspecs *sp if (specs->u.bitint_prec == -1) specs->type = integer_type_node; else - specs->type = build_bitint_type (specs->u.bitint_prec, - specs->unsigned_p); + { + pedwarn_c11 (specs->locations[cdw_typespec], OPT_Wpedantic, + "ISO C does not support %<%s_BitInt(%d)%> before C2X", + specs->unsigned_p ? "unsigned " + : specs->signed_p ? "signed " : "", + specs->u.bitint_prec); + specs->type = build_bitint_type (specs->u.bitint_prec, + specs->unsigned_p); + } break; default: gcc_unreachable (); --- gcc/c/c-typeck.cc.jj 2023-08-10 09:26:39.781509641 +0200 +++ gcc/c/c-typeck.cc 2023-08-10 10:03:00.722917789 +0200 @@ -819,6 +819,12 @@ c_common_type (tree t1, tree t2) return t1; else if (code2 == COMPLEX_TYPE && TREE_TYPE (t2) == subtype) return t2; + else if (TREE_CODE (subtype) == BITINT_TYPE) + { + sorry ("%<_Complex _BitInt(%d)%> unsupported", + TYPE_PRECISION (subtype)); + return code1 == COMPLEX_TYPE ? t1 : t2; + } else return build_complex_type (subtype); } --- gcc/c-family/c-attribs.cc.jj 2023-06-03 15:32:04.311412926 +0200 +++ gcc/c-family/c-attribs.cc 2023-08-10 10:07:05.222377604 +0200 @@ -4366,7 +4366,8 @@ type_valid_for_vector_size (tree type, t && GET_MODE_CLASS (orig_mode) != MODE_INT && !ALL_SCALAR_FIXED_POINT_MODE_P (orig_mode)) || !tree_fits_uhwi_p (TYPE_SIZE_UNIT (type)) - || TREE_CODE (type) == BOOLEAN_TYPE) + || TREE_CODE (type) == BOOLEAN_TYPE + || TREE_CODE (type) == BITINT_TYPE) { if (error_p) error ("invalid vector type for attribute %qE", atname); --- gcc/testsuite/gcc.dg/bitint-19.c.jj 2023-08-10 09:33:49.205287806 +0200 +++ gcc/testsuite/gcc.dg/bitint-19.c 2023-08-10 09:36:43.312765194 +0200 @@ -0,0 +1,16 @@ +/* PR c/102989 */ +/* { dg-do compile { target bitint } } */ +/* { dg-options "-std=gnu2x" } */ + +#define expr_has_type(e, t) _Generic (e, default : 0, t : 1) + +void +foo (_Complex int ci, _Complex long long cl) +{ + _BitInt(__SIZEOF_INT__ * __CHAR_BIT__ - 1) bi = 0wb; + _BitInt(__SIZEOF_LONG_LONG__ * __CHAR_BIT__ - 1) bl = 0wb; + static_assert (expr_has_type (ci + bi, _Complex int)); + static_assert (expr_has_type (cl + bl, _Complex long long)); + static_assert (expr_has_type (bi + ci, _Complex int)); + static_assert (expr_has_type (bl + cl, _Complex long long)); +} --- gcc/testsuite/gcc.dg/bitint-20.c.jj 2023-08-10 09:40:14.340707650 +0200 +++ gcc/testsuite/gcc.dg/bitint-20.c 2023-08-10 10:04:35.306548279 +0200 @@ -0,0 +1,16 @@ +/* PR c/102989 */ +/* { dg-do compile { target bitint } } */ +/* { dg-options "-std=gnu2x" } */ + +void +foo (_Complex int ci, _Complex long long cl) +{ + _BitInt(__SIZEOF_INT__ * __CHAR_BIT__ + 1) bi = 0wb; + ci + bi; /* { dg-message "unsupported" } */ + bi + ci; /* { dg-message "unsupported" } */ +#if __BITINT_MAXWIDTH__ >= 575 + _BitInt(575) bw = 0wb; + cl + bw; /* { dg-message "unsupported" "" { target bitint575 } } */ + bw + cl; /* { dg-message "unsupported" "" { target bitint575 } } */ +#endif +} --- gcc/testsuite/gcc.dg/bitint-21.c.jj 2023-08-10 10:07:31.393998652 +0200 +++ gcc/testsuite/gcc.dg/bitint-21.c 2023-08-10 10:14:14.303164800 +0200 @@ -0,0 +1,11 @@ +/* PR c/102989 */ +/* { dg-do compile { target bitint } } */ +/* { dg-options "-std=gnu2x" } */ + +#define IB __SIZEOF_INT__ * __CHAR_BIT__ +typedef _BitInt(IB) V1 __attribute__((vector_size (sizeof (_BitInt(IB))))); /* { dg-error "invalid vector type for attribute 'vector_size'" } */ +typedef _BitInt(IB) V2 __attribute__((vector_size (8 * sizeof (_BitInt(IB))))); /* { dg-error "invalid vector type for attribute 'vector_size'" } */ +#if __BITINT_MAXWIDTH__ >= 575 +typedef _BitInt(575) V3 __attribute__((vector_size (sizeof (_BitInt(575))))); /* { dg-error "invalid vector type for attribute 'vector_size'" "" { target bitint575 } } */ +typedef _BitInt(575) V3 __attribute__((vector_size (16 * sizeof (_BitInt(575))))); /* { dg-error "invalid vector type for attribute 'vector_size'" "" { target bitint575 } } */ +#endif --- gcc/testsuite/gcc.dg/bitint-22.c.jj 2023-08-10 11:51:51.975802981 +0200 +++ gcc/testsuite/gcc.dg/bitint-22.c 2023-08-10 11:52:16.923446548 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile { target bitint } } +// { dg-options "-std=c2x -pedantic-errors" } + +_BitInt(63) a; +signed _BitInt(15) b; +unsigned _BitInt(31) c; +int d = 21wb; +long long e = 60594869054uwb; +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 +#endif +#if 0uwb == 0 +#endif --- gcc/testsuite/gcc.dg/bitint-23.c.jj 2023-08-10 11:52:29.611265273 +0200 +++ gcc/testsuite/gcc.dg/bitint-23.c 2023-08-10 11:55:03.702063742 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile { target bitint } } +// { dg-options "-std=c2x -pedantic-errors -Wc11-c2x-compat" } + +_BitInt(63) a; /* { dg-warning "ISO C does not support '_BitInt\\\(63\\\)' before C2X" } */ +signed _BitInt(15) b; /* { dg-warning "ISO C does not support 'signed _BitInt\\\(15\\\)' before C2X" } */ +unsigned _BitInt(31) c; /* { dg-warning "ISO C does not support 'unsigned _BitInt\\\(31\\\)' before C2X" } */ +int d = 21wb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +long long e = 60594869054uwb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif +#if 0uwb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif --- gcc/testsuite/gcc.dg/bitint-24.c.jj 2023-08-10 11:56:03.403210774 +0200 +++ gcc/testsuite/gcc.dg/bitint-24.c 2023-08-10 11:56:13.037073138 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile { target bitint } } +// { dg-options "-std=c11" } + +_BitInt(63) a; +signed _BitInt(15) b; +unsigned _BitInt(31) c; +int d = 21wb; +long long e = 60594869054uwb; +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 +#endif +#if 0uwb == 0 +#endif --- gcc/testsuite/gcc.dg/bitint-25.c.jj 2023-08-10 11:56:21.499952227 +0200 +++ gcc/testsuite/gcc.dg/bitint-25.c 2023-08-10 11:56:36.468738364 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile { target bitint } } +// { dg-options "-std=c11 -Wno-c11-c2x-compat -pedantic-errors" } + +_BitInt(63) a; +signed _BitInt(15) b; +unsigned _BitInt(31) c; +int d = 21wb; +long long e = 60594869054uwb; +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 +#endif +#if 0uwb == 0 +#endif --- gcc/testsuite/gcc.dg/bitint-26.c.jj 2023-08-10 11:56:56.423453266 +0200 +++ gcc/testsuite/gcc.dg/bitint-26.c 2023-08-10 11:57:41.335811588 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile { target bitint } } +// { dg-options "-std=c11 -pedantic" } + +_BitInt(63) a; /* { dg-warning "ISO C does not support '_BitInt\\\(63\\\)' before C2X" } */ +signed _BitInt(15) b; /* { dg-warning "ISO C does not support 'signed _BitInt\\\(15\\\)' before C2X" } */ +unsigned _BitInt(31) c; /* { dg-warning "ISO C does not support 'unsigned _BitInt\\\(31\\\)' before C2X" } */ +int d = 21wb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +long long e = 60594869054uwb; /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif +#if 0uwb == 0 /* { dg-warning "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif --- gcc/testsuite/gcc.dg/bitint-27.c.jj 2023-08-10 11:57:23.690063697 +0200 +++ gcc/testsuite/gcc.dg/bitint-27.c 2023-08-10 11:57:57.352582755 +0200 @@ -0,0 +1,18 @@ +// PR c/102989 +// { dg-do compile { target bitint } } +// { dg-options "-std=c11 -pedantic-errors" } + +_BitInt(63) a; /* { dg-error "ISO C does not support '_BitInt\\\(63\\\)' before C2X" } */ +signed _BitInt(15) b; /* { dg-error "ISO C does not support 'signed _BitInt\\\(15\\\)' before C2X" } */ +unsigned _BitInt(31) c; /* { dg-error "ISO C does not support 'unsigned _BitInt\\\(31\\\)' before C2X" } */ +int d = 21wb; /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +long long e = 60594869054uwb; /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +__extension__ _BitInt(63) f; +__extension__ _BitInt(15) g; +__extension__ unsigned _BitInt(31) h; +int i = __extension__ 21wb; +long long j = __extension__ 60594869054uwb; +#if 0wb == 0 /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif +#if 0uwb == 0 /* { dg-error "ISO C does not support literal 'wb' suffixes before C2X" } */ +#endif --- gcc/testsuite/g++.dg/ext/bitint1.C.jj 2023-08-10 10:42:33.884601671 +0200 +++ gcc/testsuite/g++.dg/ext/bitint1.C 2023-08-10 10:41:44.595312345 +0200 @@ -0,0 +1,9 @@ +// PR c/102989 +// { dg-do compile } + +_BitInt(63) a; // { dg-error "expected" } +unsigned _BitInt(31) b; // { dg-error "expected" } +int c = 21wb; // { dg-error "invalid suffix \"wb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"wb'" "" { target c++11 } .-1 } +long long d = 60594869054uwb; // { dg-error "invalid suffix \"uwb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"uwb'" "" { target c++11 } .-1 } --- gcc/testsuite/g++.dg/ext/bitint2.C.jj 2023-08-10 10:42:41.950485375 +0200 +++ gcc/testsuite/g++.dg/ext/bitint2.C 2023-08-10 10:42:57.033267905 +0200 @@ -0,0 +1,10 @@ +// PR c/102989 +// { dg-do compile } +// { dg-options "" } + +_BitInt(63) a; // { dg-error "expected" } +unsigned _BitInt(31) b; // { dg-error "expected" } +int c = 21wb; // { dg-error "invalid suffix \"wb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"wb'" "" { target c++11 } .-1 } +long long d = 60594869054uwb; // { dg-error "invalid suffix \"uwb\" on integer constant" "" { target c++98_only } } + // { dg-error "unable to find numeric literal operator 'operator\"\"uwb'" "" { target c++11 } .-1 } --- gcc/testsuite/g++.dg/ext/bitint3.C.jj 2023-08-10 10:43:51.410483886 +0200 +++ gcc/testsuite/g++.dg/ext/bitint3.C 2023-08-10 10:50:06.969068962 +0200 @@ -0,0 +1,8 @@ +// PR c/102989 +// { dg-do compile { target c++11 } } + +constexpr int operator""wb (unsigned long long) { return 0; } // { dg-warning "reserved for future standardization" } +constexpr int operator""uwb (unsigned long long) { return 1; } // { dg-warning "reserved for future standardization" } + +static_assert (-42wb == 0, ""); +static_assert (81uwb == 1, ""); --- gcc/testsuite/g++.dg/ext/bitint4.C.jj 2023-08-10 10:45:20.503199319 +0200 +++ gcc/testsuite/g++.dg/ext/bitint4.C 2023-08-10 10:50:21.345861685 +0200 @@ -0,0 +1,9 @@ +// PR c/102989 +// { dg-do compile { target c++11 } } +// { dg-options "" } + +constexpr int operator""wb (unsigned long long) { return 0; } // { dg-warning "reserved for future standardization" } +constexpr int operator""uwb (unsigned long long) { return 1; } // { dg-warning "reserved for future standardization" } + +static_assert (-42wb == 0, ""); +static_assert (81uwb == 1, ""); --- libcpp/expr.cc.jj 2023-08-10 09:26:39.782509626 +0200 +++ libcpp/expr.cc 2023-08-10 11:44:29.337127064 +0200 @@ -856,6 +856,29 @@ cpp_classify_number (cpp_reader *pfile, virtual_location, 0, message); } + if ((result & CPP_N_BITINT) != 0 + && CPP_OPTION (pfile, cpp_warn_c11_c2x_compat) != 0) + { + if (CPP_OPTION (pfile, cpp_warn_c11_c2x_compat) > 0) + { + const char *message = N_("ISO C does not support literal " + "%<wb%> suffixes before C2X"); + if (CPP_PEDANTIC (pfile) && !CPP_OPTION (pfile, true_false)) + cpp_pedwarning_with_line (pfile, CPP_W_C11_C2X_COMPAT, + virtual_location, 0, message); + else + cpp_warning_with_line (pfile, CPP_W_C11_C2X_COMPAT, + virtual_location, 0, message); + } + else if (CPP_PEDANTIC (pfile) && !CPP_OPTION (pfile, true_false)) + { + const char *message = N_("ISO C does not support literal " + "%<wb%> suffixes before C2X"); + cpp_error_with_line (pfile, CPP_DL_PEDWARN, virtual_location, 0, + message); + } + } + result |= CPP_N_INTEGER; } Jakub ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 13/12 v2] C _BitInt incremental fixes [PR102989] 2023-08-10 15:22 ` [PATCH 13/12 v2] " Jakub Jelinek @ 2023-09-05 22:26 ` Joseph Myers 0 siblings, 0 replies; 17+ messages in thread From: Joseph Myers @ 2023-09-05 22:26 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc-patches On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > On Thu, Aug 10, 2023 at 12:10:07PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Here is an incremental patch which does that: > > Bootstrap/regtest on i686-linux (next to x86_64-linux where it went fine) > revealed I forgot to add { target bitint } to dg-do compile lines. > > Here is an updated patch which does that and passes even on i686-linux. This incremental patch is OK. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-09 18:14 [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek 2023-08-09 21:17 ` Joseph Myers @ 2023-08-21 15:24 ` Jakub Jelinek 2023-08-21 17:32 ` Joseph Myers ` (2 more replies) 2023-09-18 11:39 ` Matthew Malcomson 2 siblings, 3 replies; 17+ messages in thread From: Jakub Jelinek @ 2023-08-21 15:24 UTC (permalink / raw) To: Joseph S. Myers, Richard Biener; +Cc: gcc-patches Hi! On Wed, Aug 09, 2023 at 08:14:14PM +0200, Jakub Jelinek via Gcc-patches wrote: > Jakub Jelinek (12): > expr: Small optimization [PR102989] > lto-streamer-in: Adjust assert [PR102989] > phiopt: Fix phiopt ICE on vops [PR102989] > Middle-end _BitInt support [PR102989] > _BitInt lowering support [PR102989] > i386: Enable _BitInt on x86-64 [PR102989] > ubsan: _BitInt -fsanitize=undefined support [PR102989] > libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989] > libgcc _BitInt support [PR102989] > C _BitInt support [PR102989] > testsuite part 1 for _BitInt support [PR102989] > testsuite part 2 for _BitInt support [PR102989] + C _BitInt incremental fixes [PR102989] I'd like to ping this patch series. First 3 patches are committed, the rest awaits patch review. Joseph, could I ask now at least for an overall design review of the C patches (8-10,13) whether its interfaces with middle-end are ok, so that Richi can review the middle-end parts? Thanks. Jakub ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-21 15:24 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek @ 2023-08-21 17:32 ` Joseph Myers 2023-08-22 11:28 ` [PATCH 14/12] libgcc _BitInt helper documentation [PR102989] Jakub Jelinek 2023-08-22 22:48 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Andrew Pinski 2023-08-28 9:04 ` Patch ping^2 " Jakub Jelinek 2 siblings, 1 reply; 17+ messages in thread From: Joseph Myers @ 2023-08-21 17:32 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Biener, gcc-patches On Mon, 21 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Joseph, could I ask now at least for an overall design review of the > C patches (8-10,13) whether its interfaces with middle-end are ok, > so that Richi can review the middle-end parts? I am fine with the interface to the middle-end parts. I think the libgcc functions (i.e. those exported by libgcc, to which references are generated by the compiler) need documenting in libgcc.texi. Internal functions or macros in the libgcc patch need appropriate comments specifying their semantics; especially FP_TO_BITINT and FP_FROM_BITINT which have a lot of arguments and no comments saying what the semantics of the macros and their arguments are supposed to me. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 14/12] libgcc _BitInt helper documentation [PR102989] 2023-08-21 17:32 ` Joseph Myers @ 2023-08-22 11:28 ` Jakub Jelinek 2023-09-01 21:32 ` Joseph Myers 0 siblings, 1 reply; 17+ messages in thread From: Jakub Jelinek @ 2023-08-22 11:28 UTC (permalink / raw) To: Joseph Myers; +Cc: Richard Biener, gcc-patches On Mon, Aug 21, 2023 at 05:32:04PM +0000, Joseph Myers wrote: > I think the libgcc functions (i.e. those exported by libgcc, to which > references are generated by the compiler) need documenting in libgcc.texi. > Internal functions or macros in the libgcc patch need appropriate comments > specifying their semantics; especially FP_TO_BITINT and FP_FROM_BITINT > which have a lot of arguments and no comments saying what the semantics of > the macros and their arguments are supposed to me. Here is an incremental patch which does that. 2023-08-22 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/ * doc/libgcc.texi (Bit-precise integer arithmetic functions): Document general rules for _BitInt support library functions and document __mulbitint3 and __divmodbitint4. (Conversion functions): Document __fix{s,d,x,t}fbitint, __floatbitint{s,d,x,t,h,b}f, __bid_fix{s,d,t}dbitint and __bid_floatbitint{s,d,t}d. libgcc/ * libgcc2.c (bitint_negate): Add function comment. * soft-fp/bitint.h (bitint_negate): Add function comment. (FP_TO_BITINT, FP_FROM_BITINT): Add comment explaining the macros. --- gcc/doc/libgcc.texi.jj 2023-01-16 11:52:16.115733593 +0100 +++ gcc/doc/libgcc.texi 2023-08-22 12:35:08.561348126 +0200 @@ -218,6 +218,51 @@ These functions return the number of bit These functions return the @var{a} byteswapped. @end deftypefn +@subsection Bit-precise integer arithmetic functions + +@code{_BitInt(@var{N})} library functions operate on arrays of limbs, where +each limb has @code{__LIBGCC_BITINT_LIMB_WIDTH__} bits and the limbs are +ordered according to @code{__LIBGCC_BITINT_ORDER__} ordering. The most +significant limb if @var{N} is not divisible by +@code{__LIBGCC_BITINT_LIMB_WIDTH__} contains padding bits which should be +ignored on read (sign or zero extended), but extended on write. For the +library functions, all bit-precise integers regardless of @var{N} are +represented like that, even when the target ABI says that for some small +@var{N} they should be represented differently in memory. A pointer +to the array of limbs argument is always accompanied with a bit size +argument. If that argument is positive, it is number of bits and the +number is assumed to be zero-extended to infinite precision, if that +argument is negative, it is negated number of bits above which all bits +are assumed to be sign-extended to infinite precision. These number of bits +arguments don't need to match actual @var{N} for the operation used in the +source, they could be lowered because of sign or zero extensions on the +input or because value-range optimization figures value will need certain +lower number of bits. For big-endian ordering of limbs, when lowering +the bit size argument the pointer argument needs to be adjusted as well. +Negative bit size argument should be always smaller or equal to @code{-2}, +because @code{signed _BitInt(1)} is not valid. +For output arguments, either the corresponding bit size argument should +be always positive (for multiplication and division), or is negative when +the output of conversion from floating-point value is signed and positive +when unsigned. The arrays of limbs output arguments point to should not +overlap any inputs, while input arrays of limbs can overlap. +@code{UBILtype} below stands for unsigned integer type with +@code{__LIBGCC_BITINT_LIMB_WIDTH__} bit precision. + +@deftypefn {Runtime Function} void __mulbitint3 (@code{UBILtype} *@var{ret}, int32_t @var{retprec}, const @code{UBILtype} *u, int32_t @var{uprec}, const @code{UBILtype} *v, int32_t @var{vprec}) +This function multiplies bit-precise integer operands @var{u} and @var{v} and stores +result into @var{retprec} precision bit-precise integer result @var{ret}. +@end deftypefn + +@deftypefn {Runtime Function} void __divmodbitint4 (@code{UBILtype} *@var{q}, int32_t @var{qprec}, @code{UBILtype} *@var{r}, int32_t @var{rprec}, const @code{UBILtype} *u, int32_t @var{uprec}, const @code{UBILtype} *v, int32_t @var{vprec}) +This function divides bit-precise integer operands @var{u} and @var{v} and stores +quotient into @var{qprec} precision bit-precise integer result @var{q} +(unless @var{q} is @code{NULL} and @var{qprec} is 0, in that case quotient +is not stored anywhere) and remainder into @var{rprec} precision bit-precise +integer result @var{r} (similarly, unless @var{r} is @code{NULL} and @var{rprec} +is 0). +@end deftypefn + @node Soft float library routines @section Routines for floating point emulation @cindex soft float library @@ -384,6 +429,27 @@ These functions convert @var{i}, an unsi These functions convert @var{i}, an unsigned long long, to floating point. @end deftypefn +@deftypefn {Runtime Function} void __fixsfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, float @var{a}) +@deftypefnx {Runtime Function} void __fixdfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, double @var{a}) +@deftypefnx {Runtime Function} void __fixxfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, __float80 @var{a}) +@deftypefnx {Runtime Function} void __fixtfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Float128 @var{a}) +These functions convert @var{a} to bit-precise integer @var{r}, rounding toward zero. +If @var{rprec} is positive, it converts to unsigned bit-precise integer and +negative values all become zero, if @var{rprec} is negative, it converts +to signed bit-precise integer. +@end deftypefn + +@deftypefn {Runtime Function} float __floatbitintsf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} double __floatbitintdf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} __float80 __floatbitintxf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Float128 __floatbitinttf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Float16 __floatbitinthf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} __bf16 __floatbitintbf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +These functions convert bit-precise integer @var{i} to floating point. If +@var{iprec} is positive, it is conversion from unsigned bit-precise integer, +otherwise from signed bit-precise integer. +@end deftypefn + @subsection Comparison functions There are two sets of basic comparison functions. @@ -707,6 +773,23 @@ These functions convert @var{i}, an unsi These functions convert @var{i}, an unsigned long, to decimal floating point. @end deftypefn +@deftypefn {Runtime Function} void __bid_fixsdbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal32 @var{a}) +@deftypefnx {Runtime Function} void __bid_fixddbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal64 @var{a}) +@deftypefnx {Runtime Function} void __bid_fixtdbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal128 @var{a}) +These functions convert @var{a} to bit-precise integer @var{r}, rounding toward zero. +If @var{rprec} is positive, it converts to unsigned bit-precise integer and +negative values all become zero, if @var{rprec} is negative, it converts +to signed bit-precise integer. +@end deftypefn + +@deftypefn {Runtime Function} _Decimal32 __bid_floatbitintsd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Decimal64 __bid_floatbitintdd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Decimal128 __bid_floatbitinttd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +These functions convert bit-precise integer @var{i} to decimal floating point. If +@var{iprec} is positive, it is conversion from unsigned bit-precise integer, +otherwise from signed bit-precise integer. +@end deftypefn + @subsection Comparison functions @deftypefn {Runtime Function} int __dpd_unordsd2 (_Decimal32 @var{a}, _Decimal32 @var{b}) --- libgcc/libgcc2.c.jj 2023-08-22 11:21:31.549370982 +0200 +++ libgcc/libgcc2.c 2023-08-22 13:24:46.198998697 +0200 @@ -1640,6 +1640,8 @@ __mulbitint3 (UWtype *ret, SItype retpre #endif #ifdef L_divmodbitint4 +/* D = -S. */ + static void bitint_negate (UWtype *d, const UWtype *s, SItype n) { --- libgcc/soft-fp/bitint.h.jj 2023-08-22 11:21:31.583370543 +0200 +++ libgcc/soft-fp/bitint.h 2023-08-22 13:06:01.346092498 +0200 @@ -160,6 +160,9 @@ bitint_reduce_prec (const UBILtype **p, # define BITINT_END(be, le) (le) #endif +/* Negate N limbs from S into D. D and S should point to + the least significant limb. */ + static inline __attribute__((__always_inline__)) void bitint_negate (UBILtype *d, const UBILtype *s, SItype n) { @@ -175,6 +178,19 @@ bitint_negate (UBILtype *d, const UBILty while (--n); } +/* Common final part of __fix?fbitint conversion functions. + The A floating point value should have been converted using + soft-fp macros into RV, U##DI##type DI##_BITS precise normal + integral type and SHIFT, how many bits should that value be + shifted to the left. R is pointer to limbs array passed to the + function, RN number of limbs in it, ARPREC absolute value of + RPREC argument passed to it, RSIZE number of significant bits in RV. + RSIGNED is non-zero if the result is signed bit-precise integer, + otherwise zero. If OVF is true, instead of storing RV shifted left + by SHIFT bits and zero or sign extended store minimum or maximum + of the signed or unsigned bit-precise integer type depending on if + RV contains the minimum or maximum signed or unsigned value. */ + #define FP_TO_BITINT(r, rn, arprec, shift, rv, rsize, rsigned, ovf, DI) \ if (ovf) \ { \ @@ -232,6 +248,16 @@ bitint_negate (UBILtype *d, const UBILty * sizeof (UBILtype)); \ } +/* Common initial part of __floatbitint?f conversion functions. + I and IPREC are arguments passed to those functions, convert that + into a pair of DI##type IV integer and SHIFT, such that converting + IV to floating point and multiplicating that by pow (2, SHIFT) + gives the expected result. IV size needs to be chosen such that + it is large than number of bits in floating-point mantissa and + contains there even at least a two bits below the mantissa for + rounding purposes. If any of the SHIFT bits shifted out is non-zero, + the least significant bit should be non-zero. */ + #define FP_FROM_BITINT(i, iprec, iv, shift, DI) \ do \ { \ Jakub ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 14/12] libgcc _BitInt helper documentation [PR102989] 2023-08-22 11:28 ` [PATCH 14/12] libgcc _BitInt helper documentation [PR102989] Jakub Jelinek @ 2023-09-01 21:32 ` Joseph Myers 2023-09-02 11:41 ` Jakub Jelinek 0 siblings, 1 reply; 17+ messages in thread From: Joseph Myers @ 2023-09-01 21:32 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Biener, gcc-patches On Tue, 22 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > +significant limb if @var{N} is not divisible by @var{N} should be @var{n}, throughout. > +@deftypefn {Runtime Function} void __bid_fixsdbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal32 @var{a}) > +@deftypefnx {Runtime Function} void __bid_fixddbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal64 @var{a}) > +@deftypefnx {Runtime Function} void __bid_fixtdbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal128 @var{a}) > +These functions convert @var{a} to bit-precise integer @var{r}, rounding toward zero. > +If @var{rprec} is positive, it converts to unsigned bit-precise integer and > +negative values all become zero, if @var{rprec} is negative, it converts > +to signed bit-precise integer. > +@end deftypefn > + > +@deftypefn {Runtime Function} _Decimal32 __bid_floatbitintsd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) > +@deftypefnx {Runtime Function} _Decimal64 __bid_floatbitintdd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) > +@deftypefnx {Runtime Function} _Decimal128 __bid_floatbitinttd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) > +These functions convert bit-precise integer @var{i} to decimal floating point. If > +@var{iprec} is positive, it is conversion from unsigned bit-precise integer, > +otherwise from signed bit-precise integer. > +@end deftypefn The documentation for __bid_* should say explicitly that these functions are for BID format (assuming it's intended that functions for DPD format should use __dpd_* when support is added for an architecture using DPD). > +/* Common final part of __fix?fbitint conversion functions. > + The A floating point value should have been converted using > + soft-fp macros into RV, U##DI##type DI##_BITS precise normal > + integral type and SHIFT, how many bits should that value be > + shifted to the left. R is pointer to limbs array passed to the > + function, RN number of limbs in it, ARPREC absolute value of > + RPREC argument passed to it, RSIZE number of significant bits in RV. > + RSIGNED is non-zero if the result is signed bit-precise integer, > + otherwise zero. If OVF is true, instead of storing RV shifted left > + by SHIFT bits and zero or sign extended store minimum or maximum > + of the signed or unsigned bit-precise integer type depending on if > + RV contains the minimum or maximum signed or unsigned value. */ As I understand it, OVF is also for the case of a zero result from input close to zero, for signed types (when that's not the maximum or minimum) in addition to unsigned types. > +/* Common initial part of __floatbitint?f conversion functions. > + I and IPREC are arguments passed to those functions, convert that > + into a pair of DI##type IV integer and SHIFT, such that converting > + IV to floating point and multiplicating that by pow (2, SHIFT) > + gives the expected result. IV size needs to be chosen such that > + it is large than number of bits in floating-point mantissa and "large than" -> "larger than". This patch is OK with those fixes. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 14/12] libgcc _BitInt helper documentation [PR102989] 2023-09-01 21:32 ` Joseph Myers @ 2023-09-02 11:41 ` Jakub Jelinek 0 siblings, 0 replies; 17+ messages in thread From: Jakub Jelinek @ 2023-09-02 11:41 UTC (permalink / raw) To: Joseph Myers; +Cc: Richard Biener, gcc-patches On Fri, Sep 01, 2023 at 09:32:22PM +0000, Joseph Myers wrote: > This patch is OK with those fixes. Thanks, here is the updated patch. Queued with the rest of approved patches. 2023-09-02 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/ * doc/libgcc.texi (Bit-precise integer arithmetic functions): Document general rules for _BitInt support library functions and document __mulbitint3 and __divmodbitint4. (Conversion functions): Document __fix{s,d,x,t}fbitint, __floatbitint{s,d,x,t,h,b}f, __bid_fix{s,d,t}dbitint and __bid_floatbitint{s,d,t}d. libgcc/ * libgcc2.c (bitint_negate): Add function comment. * soft-fp/bitint.h (bitint_negate): Add function comment. (FP_TO_BITINT, FP_FROM_BITINT): Add comment explaining the macros. --- gcc/doc/libgcc.texi.jj 2023-01-16 11:52:16.115733593 +0100 +++ gcc/doc/libgcc.texi 2023-08-22 12:35:08.561348126 +0200 @@ -218,6 +218,51 @@ These functions return the number of bit These functions return the @var{a} byteswapped. @end deftypefn +@subsection Bit-precise integer arithmetic functions + +@code{_BitInt(@var{n})} library functions operate on arrays of limbs, where +each limb has @code{__LIBGCC_BITINT_LIMB_WIDTH__} bits and the limbs are +ordered according to @code{__LIBGCC_BITINT_ORDER__} ordering. The most +significant limb if @var{n} is not divisible by +@code{__LIBGCC_BITINT_LIMB_WIDTH__} contains padding bits which should be +ignored on read (sign or zero extended), but extended on write. For the +library functions, all bit-precise integers regardless of @var{n} are +represented like that, even when the target ABI says that for some small +@var{n} they should be represented differently in memory. A pointer +to the array of limbs argument is always accompanied with a bit size +argument. If that argument is positive, it is number of bits and the +number is assumed to be zero-extended to infinite precision, if that +argument is negative, it is negated number of bits above which all bits +are assumed to be sign-extended to infinite precision. These number of bits +arguments don't need to match actual @var{n} for the operation used in the +source, they could be lowered because of sign or zero extensions on the +input or because value-range optimization figures value will need certain +lower number of bits. For big-endian ordering of limbs, when lowering +the bit size argument the pointer argument needs to be adjusted as well. +Negative bit size argument should be always smaller or equal to @code{-2}, +because @code{signed _BitInt(1)} is not valid. +For output arguments, either the corresponding bit size argument should +be always positive (for multiplication and division), or is negative when +the output of conversion from floating-point value is signed and positive +when unsigned. The arrays of limbs output arguments point to should not +overlap any inputs, while input arrays of limbs can overlap. +@code{UBILtype} below stands for unsigned integer type with +@code{__LIBGCC_BITINT_LIMB_WIDTH__} bit precision. + +@deftypefn {Runtime Function} void __mulbitint3 (@code{UBILtype} *@var{ret}, int32_t @var{retprec}, const @code{UBILtype} *u, int32_t @var{uprec}, const @code{UBILtype} *v, int32_t @var{vprec}) +This function multiplies bit-precise integer operands @var{u} and @var{v} and stores +result into @var{retprec} precision bit-precise integer result @var{ret}. +@end deftypefn + +@deftypefn {Runtime Function} void __divmodbitint4 (@code{UBILtype} *@var{q}, int32_t @var{qprec}, @code{UBILtype} *@var{r}, int32_t @var{rprec}, const @code{UBILtype} *u, int32_t @var{uprec}, const @code{UBILtype} *v, int32_t @var{vprec}) +This function divides bit-precise integer operands @var{u} and @var{v} and stores +quotient into @var{qprec} precision bit-precise integer result @var{q} +(unless @var{q} is @code{NULL} and @var{qprec} is 0, in that case quotient +is not stored anywhere) and remainder into @var{rprec} precision bit-precise +integer result @var{r} (similarly, unless @var{r} is @code{NULL} and @var{rprec} +is 0). +@end deftypefn + @node Soft float library routines @section Routines for floating point emulation @cindex soft float library @@ -384,6 +429,27 @@ These functions convert @var{i}, an unsi These functions convert @var{i}, an unsigned long long, to floating point. @end deftypefn +@deftypefn {Runtime Function} void __fixsfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, float @var{a}) +@deftypefnx {Runtime Function} void __fixdfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, double @var{a}) +@deftypefnx {Runtime Function} void __fixxfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, __float80 @var{a}) +@deftypefnx {Runtime Function} void __fixtfbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Float128 @var{a}) +These functions convert @var{a} to bit-precise integer @var{r}, rounding toward zero. +If @var{rprec} is positive, it converts to unsigned bit-precise integer and +negative values all become zero, if @var{rprec} is negative, it converts +to signed bit-precise integer. +@end deftypefn + +@deftypefn {Runtime Function} float __floatbitintsf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} double __floatbitintdf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} __float80 __floatbitintxf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Float128 __floatbitinttf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Float16 __floatbitinthf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} __bf16 __floatbitintbf (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +These functions convert bit-precise integer @var{i} to floating point. If +@var{iprec} is positive, it is conversion from unsigned bit-precise integer, +otherwise from signed bit-precise integer. +@end deftypefn + @subsection Comparison functions There are two sets of basic comparison functions. @@ -707,6 +773,23 @@ These functions convert @var{i}, an unsi These functions convert @var{i}, an unsigned long, to decimal floating point. @end deftypefn +@deftypefn {Runtime Function} void __bid_fixsdbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal32 @var{a}) +@deftypefnx {Runtime Function} void __bid_fixddbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal64 @var{a}) +@deftypefnx {Runtime Function} void __bid_fixtdbitint (@code{UBILtype} *@var{r}, int32_t @var{rprec}, _Decimal128 @var{a}) +These functions convert @var{a} to bit-precise integer @var{r}, rounding toward zero. +If @var{rprec} is positive, it converts to unsigned bit-precise integer and +negative values all become zero, if @var{rprec} is negative, it converts +to signed bit-precise integer. So far implemented for BID format only. +@end deftypefn + +@deftypefn {Runtime Function} _Decimal32 __bid_floatbitintsd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Decimal64 __bid_floatbitintdd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +@deftypefnx {Runtime Function} _Decimal128 __bid_floatbitinttd (@code{UBILtype} *@var{i}, int32_t @var{iprec}) +These functions convert bit-precise integer @var{i} to decimal floating point. If +@var{iprec} is positive, it is conversion from unsigned bit-precise integer, +otherwise from signed bit-precise integer. So far implemented for BID format only. +@end deftypefn + @subsection Comparison functions @deftypefn {Runtime Function} int __dpd_unordsd2 (_Decimal32 @var{a}, _Decimal32 @var{b}) --- libgcc/libgcc2.c.jj 2023-08-22 11:21:31.549370982 +0200 +++ libgcc/libgcc2.c 2023-08-22 13:24:46.198998697 +0200 @@ -1640,6 +1640,8 @@ __mulbitint3 (UWtype *ret, SItype retpre #endif #ifdef L_divmodbitint4 +/* D = -S. */ + static void bitint_negate (UWtype *d, const UWtype *s, SItype n) { --- libgcc/soft-fp/bitint.h.jj 2023-08-22 11:21:31.583370543 +0200 +++ libgcc/soft-fp/bitint.h 2023-08-22 13:06:01.346092498 +0200 @@ -160,6 +160,9 @@ bitint_reduce_prec (const UBILtype **p, # define BITINT_END(be, le) (le) #endif +/* Negate N limbs from S into D. D and S should point to + the least significant limb. */ + static inline __attribute__((__always_inline__)) void bitint_negate (UBILtype *d, const UBILtype *s, SItype n) { @@ -175,6 +178,19 @@ bitint_negate (UBILtype *d, const UBILty while (--n); } +/* Common final part of __fix?fbitint conversion functions. + The A floating point value should have been converted using + soft-fp macros into RV, U##DI##type DI##_BITS precise normal + integral type and SHIFT, how many bits should that value be + shifted to the left. R is pointer to limbs array passed to the + function, RN number of limbs in it, ARPREC absolute value of + RPREC argument passed to it, RSIZE number of significant bits in RV. + RSIGNED is non-zero if the result is signed bit-precise integer, + otherwise zero. If OVF is true, instead of storing RV shifted left + by SHIFT bits and zero or sign extended store minimum or maximum + of the signed or unsigned bit-precise integer type or zero depending on if + RV contains the minimum or maximum signed or unsigned value or zero. */ + #define FP_TO_BITINT(r, rn, arprec, shift, rv, rsize, rsigned, ovf, DI) \ if (ovf) \ { \ @@ -232,6 +248,16 @@ bitint_negate (UBILtype *d, const UBILty * sizeof (UBILtype)); \ } +/* Common initial part of __floatbitint?f conversion functions. + I and IPREC are arguments passed to those functions, convert that + into a pair of DI##type IV integer and SHIFT, such that converting + IV to floating point and multiplicating that by pow (2, SHIFT) + gives the expected result. IV size needs to be chosen such that + it is larger than number of bits in floating-point mantissa and + contains there even at least a two bits below the mantissa for + rounding purposes. If any of the SHIFT bits shifted out is non-zero, + the least significant bit should be non-zero. */ + #define FP_FROM_BITINT(i, iprec, iv, shift, DI) \ do \ { \ Jakub ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-21 15:24 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek 2023-08-21 17:32 ` Joseph Myers @ 2023-08-22 22:48 ` Andrew Pinski 2023-08-28 9:04 ` Patch ping^2 " Jakub Jelinek 2 siblings, 0 replies; 17+ messages in thread From: Andrew Pinski @ 2023-08-22 22:48 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Joseph S. Myers, Richard Biener, gcc-patches On Mon, Aug 21, 2023 at 8:25 AM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Hi! > > On Wed, Aug 09, 2023 at 08:14:14PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Jakub Jelinek (12): > > expr: Small optimization [PR102989] > > lto-streamer-in: Adjust assert [PR102989] > > phiopt: Fix phiopt ICE on vops [PR102989] > > Middle-end _BitInt support [PR102989] > > _BitInt lowering support [PR102989] > > i386: Enable _BitInt on x86-64 [PR102989] > > ubsan: _BitInt -fsanitize=undefined support [PR102989] > > libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989] > > libgcc _BitInt support [PR102989] > > C _BitInt support [PR102989] > > testsuite part 1 for _BitInt support [PR102989] > > testsuite part 2 for _BitInt support [PR102989] > > + C _BitInt incremental fixes [PR102989] > > I'd like to ping this patch series. > First 3 patches are committed, the rest awaits patch review. > > Joseph, could I ask now at least for an overall design review of the > C patches (8-10,13) whether its interfaces with middle-end are ok, > so that Richi can review the middle-end parts? On a related note, does it make sense to add this as a C++ front-end as an Extension too? I noticed clang supports it for C++. Thanks, Andrew > > Thanks. > > Jakub > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Patch ping^2 Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-21 15:24 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek 2023-08-21 17:32 ` Joseph Myers 2023-08-22 22:48 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Andrew Pinski @ 2023-08-28 9:04 ` Jakub Jelinek 2 siblings, 0 replies; 17+ messages in thread From: Jakub Jelinek @ 2023-08-28 9:04 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches Hi! On Mon, Aug 21, 2023 at 05:24:02PM +0200, Jakub Jelinek via Gcc-patches wrote: > Jakub Jelinek (12): > expr: Small optimization [PR102989] > lto-streamer-in: Adjust assert [PR102989] > phiopt: Fix phiopt ICE on vops [PR102989] > Middle-end _BitInt support [PR102989] > _BitInt lowering support [PR102989] > i386: Enable _BitInt on x86-64 [PR102989] > ubsan: _BitInt -fsanitize=undefined support [PR102989] > libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989] > libgcc _BitInt support [PR102989] > C _BitInt support [PR102989] > testsuite part 1 for _BitInt support [PR102989] > testsuite part 2 for _BitInt support [PR102989] + C _BitInt incremental fixes [PR102989] + libgcc _BitInt helper documentation [PR102989] I'd like to ping the rest of this patch series. First 3 patches are committed, next 4 are approved with commit waiting for approval of the rest, the 2 testsuite patches are also approved if you don't have further comments on them, the 3 libgcc patches and 2 C _BitInt patches need to be reviewed. https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626850.html https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626851.html https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626852.html https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627033.html https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628141.html Thanks. Jakub ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-08-09 18:14 [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek 2023-08-09 21:17 ` Joseph Myers 2023-08-21 15:24 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek @ 2023-09-18 11:39 ` Matthew Malcomson 2023-09-18 21:31 ` Joseph Myers 2 siblings, 1 reply; 17+ messages in thread From: Matthew Malcomson @ 2023-09-18 11:39 UTC (permalink / raw) To: Jakub Jelinek, Richard Biener, Joseph S. Myers, Uros Bizjak, hjl.tools Cc: gcc-patches On 8/9/23 19:14, Jakub Jelinek via Gcc-patches wrote: > It is enabled only on targets which have agreed on processor specific > ABI how to lay those out or pass as function arguments/return values, > which currently is just x86-64 I believe, would be nice if target maintainers > helped to get agreement on psABI changes and GCC 14 could enable it on far > more architectures than just one. > Hello, Do you know of any other architectures in the process of defining a psABI for _BitInt (or for that matter having defined an ABI between then and now)? We're currently working on completing the ABI for AArch64 and AArch32 hoping that it could unblock the enablement for those arches. We'd like to know about the potential clashes with other ABI's w.r.t. user-visible behaviour as part of the decision making. I'd not found any other defined ABI's online, but thought it worth asking in case I just missed it. Thanks, Matthew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/12] GCC _BitInt support [PR102989] 2023-09-18 11:39 ` Matthew Malcomson @ 2023-09-18 21:31 ` Joseph Myers 0 siblings, 0 replies; 17+ messages in thread From: Joseph Myers @ 2023-09-18 21:31 UTC (permalink / raw) To: Matthew Malcomson Cc: Jakub Jelinek, Richard Biener, Uros Bizjak, hjl.tools, gcc-patches On Mon, 18 Sep 2023, Matthew Malcomson via Gcc-patches wrote: > On 8/9/23 19:14, Jakub Jelinek via Gcc-patches wrote: > > > It is enabled only on targets which have agreed on processor specific > > ABI how to lay those out or pass as function arguments/return values, > > which currently is just x86-64 I believe, would be nice if target > > maintainers > > helped to get agreement on psABI changes and GCC 14 could enable it on far > > more architectures than just one. > > > Hello, > > Do you know of any other architectures in the process of defining a psABI for > _BitInt (or for that matter having defined an ABI between then and now)? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989#c13 has links to all the issues I filed requesting that ABIs be defined for _BitInt. At some point all GCC architecture maintainers should probably be asked to try to agree _BitInt ABIs with any psABI maintainers that may exist, or, failing a maintained psABI, with any other implementations for the architecture, or, failing other maintained implementations that support _BitInt or might do so in future, to write down a definition of the ABI being used by GCC for _BitInt on that architecture along with enabling the support in GCC. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-09-18 21:31 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-08-09 18:14 [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek 2023-08-09 21:17 ` Joseph Myers 2023-08-10 6:55 ` Richard Biener 2023-08-10 7:12 ` Jakub Jelinek 2023-08-10 7:26 ` Andrew Pinski 2023-08-10 10:10 ` [PATCH 13/12] C _BitInt incremental fixes [PR102989] Jakub Jelinek 2023-08-10 15:22 ` [PATCH 13/12 v2] " Jakub Jelinek 2023-09-05 22:26 ` Joseph Myers 2023-08-21 15:24 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Jakub Jelinek 2023-08-21 17:32 ` Joseph Myers 2023-08-22 11:28 ` [PATCH 14/12] libgcc _BitInt helper documentation [PR102989] Jakub Jelinek 2023-09-01 21:32 ` Joseph Myers 2023-09-02 11:41 ` Jakub Jelinek 2023-08-22 22:48 ` Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989] Andrew Pinski 2023-08-28 9:04 ` Patch ping^2 " Jakub Jelinek 2023-09-18 11:39 ` Matthew Malcomson 2023-09-18 21:31 ` Joseph Myers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).