[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.4 --- Comment #7 from Joseph S. Myers --- Fixed for GCC 8.4, GCC 9.3, GCC 10.
[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Joseph Myers : https://gcc.gnu.org/g:a8d3c5702a422025e42b22ce860e245b50ff57a2 commit r8-9931-ga8d3c5702a422025e42b22ce860e245b50ff57a2 Author: Joseph Myers Date: Mon Jan 13 22:15:01 2020 + Fix libdecnumber handling of non-canonical BID significands (PR middle-end/91226). As reported in bug 91226, the libdecnumber code used on the host to interpret DFP values in the BID encoding fails, for _Decimal64 and _Decimal128, to check for the case where a significand is too large and so specified in IEEE 754 to be a non-canonical encoding of the zero significand. This patch adds the required handling of that case, together with tests both using -O2 (testing this host code) and -O0 (testing libgcc code, which already worked before the patch); the tests also cover _Decimal32, which already had the required check. In the _Decimal128 case, where the code previously completely ignored the case where the first four bits of the combination field are 1100, 1101 or 1110, the logic for determining the correct quantum exponent in that case is also newly added by this patch, so tests are added for that as well (again, libgcc already handled it correctly when the conversion was done at runtime rather than at compile time). Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR middle-end/91226 libdecnumber: * bid/bid2dpd_dpd2bid.c (_bid_to_dpd64): Handle non-canonical significands. (_bid_to_dpd128): Likewise. Check for case where combination field starts 1100, 1101 or 1110. gcc/testsuite: * gcc.dg/dfp/bid-non-canonical-d128-1.c, gcc.dg/dfp/bid-non-canonical-d128-2.c, gcc.dg/dfp/bid-non-canonical-d128-3.c, gcc.dg/dfp/bid-non-canonical-d128-4.c, gcc.dg/dfp/bid-non-canonical-d32-1.c, gcc.dg/dfp/bid-non-canonical-d32-2.c, gcc.dg/dfp/bid-non-canonical-d64-1.c, gcc.dg/dfp/bid-non-canonical-d64-2.c: New tests. (cherry picked from commit 0fad54f0a88160e81c3150b63c91fd9809665474)
[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Joseph Myers : https://gcc.gnu.org/g:5b6c608019153e3dbb03e3f5f7b7a1768727f987 commit r9-8129-g5b6c608019153e3dbb03e3f5f7b7a1768727f987 Author: Joseph Myers Date: Mon Jan 13 18:45:04 2020 + Fix libdecnumber handling of non-canonical BID significands (PR middle-end/91226). As reported in bug 91226, the libdecnumber code used on the host to interpret DFP values in the BID encoding fails, for _Decimal64 and _Decimal128, to check for the case where a significand is too large and so specified in IEEE 754 to be a non-canonical encoding of the zero significand. This patch adds the required handling of that case, together with tests both using -O2 (testing this host code) and -O0 (testing libgcc code, which already worked before the patch); the tests also cover _Decimal32, which already had the required check. In the _Decimal128 case, where the code previously completely ignored the case where the first four bits of the combination field are 1100, 1101 or 1110, the logic for determining the correct quantum exponent in that case is also newly added by this patch, so tests are added for that as well (again, libgcc already handled it correctly when the conversion was done at runtime rather than at compile time). Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR middle-end/91226 libdecnumber: * bid/bid2dpd_dpd2bid.c (_bid_to_dpd64): Handle non-canonical significands. (_bid_to_dpd128): Likewise. Check for case where combination field starts 1100, 1101 or 1110. gcc/testsuite: * gcc.dg/dfp/bid-non-canonical-d128-1.c, gcc.dg/dfp/bid-non-canonical-d128-2.c, gcc.dg/dfp/bid-non-canonical-d128-3.c, gcc.dg/dfp/bid-non-canonical-d128-4.c, gcc.dg/dfp/bid-non-canonical-d32-1.c, gcc.dg/dfp/bid-non-canonical-d32-2.c, gcc.dg/dfp/bid-non-canonical-d64-1.c, gcc.dg/dfp/bid-non-canonical-d64-2.c: New tests. (cherry picked from commit 0fad54f0a88160e81c3150b63c91fd9809665474)
[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226 --- Comment #4 from Joseph S. Myers --- Fixed for GCC 10. Leaving open for now for possible backports to GCC 9 and 8 branches as a wrong-code fix.
[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226 --- Comment #3 from Joseph S. Myers --- Author: jsm28 Date: Mon Dec 9 13:59:24 2019 New Revision: 279129 URL: https://gcc.gnu.org/viewcvs?rev=279129=gcc=rev Log: Fix libdecnumber handling of non-canonical BID significands (PR middle-end/91226). As reported in bug 91226, the libdecnumber code used on the host to interpret DFP values in the BID encoding fails, for _Decimal64 and _Decimal128, to check for the case where a significand is too large and so specified in IEEE 754 to be a non-canonical encoding of the zero significand. This patch adds the required handling of that case, together with tests both using -O2 (testing this host code) and -O0 (testing libgcc code, which already worked before the patch); the tests also cover _Decimal32, which already had the required check. In the _Decimal128 case, where the code previously completely ignored the case where the first four bits of the combination field are 1100, 1101 or 1110, the logic for determining the correct quantum exponent in that case is also newly added by this patch, so tests are added for that as well (again, libgcc already handled it correctly when the conversion was done at runtime rather than at compile time). Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR middle-end/91226 libdecnumber: * bid/bid2dpd_dpd2bid.c (_bid_to_dpd64): Handle non-canonical significands. (_bid_to_dpd128): Likewise. Check for case where combination field starts 1100, 1101 or 1110. gcc/testsuite: * gcc.dg/dfp/bid-non-canonical-d128-1.c, gcc.dg/dfp/bid-non-canonical-d128-2.c, gcc.dg/dfp/bid-non-canonical-d128-3.c, gcc.dg/dfp/bid-non-canonical-d128-4.c, gcc.dg/dfp/bid-non-canonical-d32-1.c, gcc.dg/dfp/bid-non-canonical-d32-2.c, gcc.dg/dfp/bid-non-canonical-d64-1.c, gcc.dg/dfp/bid-non-canonical-d64-2.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-1.c trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-2.c trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-3.c trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-4.c trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d32-1.c trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d32-2.c trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d64-1.c trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d64-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libdecnumber/ChangeLog trunk/libdecnumber/bid/bid2dpd_dpd2bid.c
[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-06 Summary|wrong propagation of|wrong propagation of |non-canonical _Decimal64|non-canonical _Decimal64 |constant|and _Decimal128 constant ||(BID only) Ever confirmed|0 |1 --- Comment #2 from Joseph S. Myers --- Thus, confirmed.
