public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r14-8949] libgcc: Fix UB in FP_FROM_BITINT Date: Tue, 13 Feb 2024 09:33:59 +0000 (GMT) [thread overview] Message-ID: <20240213093359.06E113858408@sourceware.org> (raw) https://gcc.gnu.org/g:2ca373b7e8adf9cc0c17aecab5e1cc6c76a92f4c commit r14-8949-g2ca373b7e8adf9cc0c17aecab5e1cc6c76a92f4c Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Feb 13 10:33:08 2024 +0100 libgcc: Fix UB in FP_FROM_BITINT As I wrote earlier, I was seeing FAIL: gcc.dg/torture/bitint-24.c -O0 execution test FAIL: gcc.dg/torture/bitint-24.c -O2 execution test with the ia32 _BitInt enablement patch on i686-linux. I thought floatbitintxf.c was miscompiled with -O2 -march=i686 -mtune=generic, but it turned out to be UB in it. If a signed _BitInt to be converted to binary floating point has (after sign extension from possible partial limb to full limb) one or more most significant limbs equal to all ones and then in the limb below (the most significant non-~(UBILtype)0 limb) has the most significant limb cleared, like for 32-bit limbs 0x81582c05U, 0x0a8b01e4U, 0xc1b8b18fU, 0x2aac2a08U, -1U, -1U then bitint_reduce_prec can't reduce it to that 0x2aac2a08U limb, so msb is all ones and precision is negative (so it reduced precision from 161 to 192 bits down to 160 bits, in theory could go as low as 129 bits but that wouldn't change anything on the following behavior). But still iprec is negative, -160 here. For that case (i.e. where we are dealing with an negative input), the code was using 65 - __builtin_clzll (~msb) to compute how many relevant bits we have from the msb. Unfortunately that invokes UB for msb all ones. The right number of relevant bits in that case is 1 though (like for -2 it is 2 and -4 or -3 3 as already computed) - all we care about from that is that the most significant bit is set (i.e. the number is negative) and the bits below that should be supplied from the limbs below. So, the following patch fixes it by special casing it not to invoke UB. For msb 0 we already have a special case from before (but that is also different because msb 0 implies the whole number is 0 given the way bitint_reduce_prec works - even if we have limbs like ..., 0x80000000U, 0U the reduction can skip the most significant limb and msb then would be the one below it), so if iprec > 0, we already don't call __builtin_clzll on 0. 2024-02-13 Jakub Jelinek <jakub@redhat.com> * soft-fp/bitint.h (FP_FROM_BITINT): If iprec < 0 and msb is all ones, just set n to 1 instead of using __builtin_clzll (~msb). Diff: --- libgcc/soft-fp/bitint.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libgcc/soft-fp/bitint.h b/libgcc/soft-fp/bitint.h index cb4d822cb49b..07a7bcbb0b99 100644 --- a/libgcc/soft-fp/bitint.h +++ b/libgcc/soft-fp/bitint.h @@ -276,7 +276,11 @@ bitint_negate (UBILtype *d, const UBILtype *s, SItype n) } \ if (iprec < 0) \ { \ - n = sizeof (0ULL) * __CHAR_BIT__ + 1 - __builtin_clzll (~msb);\ + if (msb == (UBILtype) -1) \ + n = 1; \ + else \ + n = (sizeof (0ULL) * __CHAR_BIT__ + 1 \ + - __builtin_clzll (~msb)); \ if (BIL_TYPE_SIZE > DI##_BITS && n > DI##_BITS) \ { \ iv = msb >> (n - DI##_BITS); \
reply other threads:[~2024-02-13 9:33 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240213093359.06E113858408@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).