]> git.ipfire.org Git - thirdparty/gcc.git/commit
dfp, real: Fix up FLOAT_EXPR/FIX_TRUNC_EXPR constant folding between dfp and large...
authorJakub Jelinek <jakub@redhat.com>
Wed, 18 Jun 2025 06:07:22 +0000 (08:07 +0200)
committerJakub Jelinek <jakub@gcc.gnu.org>
Wed, 18 Jun 2025 06:07:22 +0000 (08:07 +0200)
commitf3002d664d1137844c714645a841a48ab57d0eaa
tree4ffe8c2b7c1c7ca220ce305e2a771678bddc9e2a
parenta0ffc9b1bfd45da5ce676a0cef419381c021f54b
dfp, real: Fix up FLOAT_EXPR/FIX_TRUNC_EXPR constant folding between dfp and large _BitInt [PR120631]

The following testcase shows that while at runtime we handle conversions
between _Decimal{64,128} and large _BitInt correctly, at compile time we
mishandle them in both directions, in one direction we end up in ICE in
decimal_from_integer callee because the char buffer is too short for the
needed number of decimal digits, in the conversion of dfp to large _BitInt
we return 0 in the wide_int.

The following patch fixes the ICE by using larger buffer (XALLOCAVEC
allocated, it will be never larger than 65536 / 3 bytes) in the larger
_BitInt case, and the other direction by setting exponent to exp % 19
and instead multiplying the result by needed powers of 10^19 (10^19 chosen
as largest power of ten that can fit into UHWI).

2025-06-18  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/120631
* real.cc (decimal_from_integer): Add digits argument, if larger than
256, use XALLOCAVEC allocated buffer.
(real_from_integer): Pass val_in's precision divided by 3 to
decimal_from_integer.
* dfp.cc (decimal_real_to_integer): For precision > 128 if finite
and exponent is large, decrease exponent and multiply resulting
wide_int by powers of 10^19.

* gcc.dg/dfp/bitint-9.c: New test.
gcc/dfp.cc
gcc/real.cc
gcc/testsuite/gcc.dg/dfp/bitint-9.c [new file with mode: 0644]