From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2153) id 06E113858408; Tue, 13 Feb 2024 09:33:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06E113858408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707816839; bh=QAEqIXTwp5H+owd1xJoCFL5pEmIE0soSr8mL4wKomd4=; h=From:To:Subject:Date:From; b=mmD2BjpC4y/ayY/9e2g5CrrXiD5EJGwjvsev9MWx4VoJwoOYUTzH+i97qgP1TbJ3D Jx0y0mahRYtX/DGnPioPE+K2S9LTJfIjxiy0gRmajrV7zKsGmvhcnwvBngr6aaeB84 Kl2MeNxqdppTdctPhGph/qPE5VZM13UQqWRMy7q8= MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" From: Jakub Jelinek To: gcc-cvs@gcc.gnu.org Subject: [gcc r14-8949] libgcc: Fix UB in FP_FROM_BITINT X-Act-Checkin: gcc X-Git-Author: Jakub Jelinek X-Git-Refname: refs/heads/master X-Git-Oldrev: 21de3391e4cecfef6ad1b60772cb55616c1bf7bd X-Git-Newrev: 2ca373b7e8adf9cc0c17aecab5e1cc6c76a92f4c Message-Id: <20240213093359.06E113858408@sourceware.org> Date: Tue, 13 Feb 2024 09:33:59 +0000 (GMT) List-Id: https://gcc.gnu.org/g:2ca373b7e8adf9cc0c17aecab5e1cc6c76a92f4c commit r14-8949-g2ca373b7e8adf9cc0c17aecab5e1cc6c76a92f4c Author: Jakub Jelinek 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 * 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); \