From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id E37F03858D37 for ; Fri, 1 Sep 2023 08:13:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E37F03858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2b962c226ceso28122581fa.3 for ; Fri, 01 Sep 2023 01:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693556032; x=1694160832; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SFKijYC6AHgWWS44RPhZvTpNwIFpXBwjTPpBHUvNbnk=; b=M/4nl4E5qLMP8BpyWZn2aW2PMcaAbvg/aFXhmb59Kqz9fk7TR+STUtk+1YnSkt/AaC hJ6BVfr3oW6P/jzbiaclMe6NNWhv0GcaHLOgLKmVfRg940M7nYgubxxUGpJlvWItwjiB vZ1IaPQRh0afba42lmqDX6rBDhNyv4kYOTuhFXq8VGiw1r2EXdJz/Vp4fqnqMpCSA3Y7 /mwVDJRkUaj++UJ/MgXHtNJCfQIZElWFzjZM4sQOPVdIWtufYwvvsvtuWfpfmkx67KIu plZ2d5ndg/BVd8QPxHOX8YHqPrQXVNu22UJzo1uTpbcRutg/1ocAvgprrTWmQ7PAqXHa CxRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693556032; x=1694160832; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SFKijYC6AHgWWS44RPhZvTpNwIFpXBwjTPpBHUvNbnk=; b=TX24otaFX6Er1jhVAojYaDE+ThqY13x6TCEZ5MFuljOhJqP9d9iqED8PVAZIznGzD0 /HHpZ3qbn1btqwfML1+37m31fsl6xf6/W4NReS9/eDEX7jw6o0u0Hc0BiCRzyQPHdtKK lPCZ3R8yY9o7kmQuL+uve+TYrh3Wl//qif0j0cvisGsPvP8Wr7mP8fExauokFjO208u+ YhEhaCxVOlJNXmTm/7NEJwDUWaCymcSHipY9l67wjo/VXNX9b/2NGdNV1dnzwQ5jDlvc XLZDfgmHTJ+8rLF48VsUbP8I8eBii1B4FdDhTeAKl5ib2IsGGW6jLY8z52nnZpRR92nr xJhw== X-Gm-Message-State: AOJu0Yw3s470xMCt5iUajadSMivwnT0VzmqYKXcB6NnlHSwFjPEW7Mh/ lPArZwrxVO3bjYECd1Zwk+OUBa6BaQry1uloclLimabH X-Google-Smtp-Source: AGHT+IHHcy7CbRn8mfp2yzkrBgV2jt/lsZEHUFU7RBv81C0qkOYrl/Rzt88vzrT95ZppaGsN4KPLBqPWuTlfgQ79bNY= X-Received: by 2002:a05:651c:104a:b0:2bc:db5a:9545 with SMTP id x10-20020a05651c104a00b002bcdb5a9545mr940610ljm.14.1693556032336; Fri, 01 Sep 2023 01:13:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 1 Sep 2023 10:13:40 +0200 Message-ID: Subject: Re: CLZ when CLZ_DEFINED_VALUE_AT_ZERO is false To: Krister Walfridsson , Andrew MacLeod Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Aug 31, 2023 at 3:58=E2=80=AFPM Krister Walfridsson via Gcc wrote: > > My translation validation tool reports some miscompilations related to th= e > internal call CLZ(0) when CLZ_DEFINED_VALUE_AT_ZERO is false, but I am no= t > sure I use the correct semantics... > > I started by modeling CLZ(0) as undefined behavior, but that made the too= l > report a miscompilation for gcc.c-torture/execute/920501-6.c where sccp > changes a loop to > > _36 =3D t_10(D) !=3D 0; > _35 =3D .CLZ (t_10(D)); > _34 =3D 63 - _35; > _33 =3D (unsigned int) _34; > _32 =3D (long long unsigned int) _33; > _31 =3D _32 + 1; > b_38 =3D _36 ? _31 : 1; > > This may call CLZ with 0, but the value is not used, so it seems > reasonable to allow this. I therefore changed my tool to treat CLZ(0) as > returning an undefined value instead (by generating it as a symbolic > value, which then makes the tool test that the IR is valid for all > values). > > This still makes this optimization fail because the calculation of _34 ma= y > overflow... :( This could be a bug in the sccp pass (which could have > done the calculation as unsigned), but fixing this would still make the > tool report a miscompilation as the ranges calculated during the dom3 pas= s > claims that _35 has a range: > _35 : [irange] int [0, 63] > > So what is the correct semantics for CLZ when CLZ_DEFINED_VALUE_AT_ZERO i= s > false? The value of .CLZ (0) is undefined then. I belive your analysis is correct= in that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes the range for _35. I wonder why we don't elide _36 ? _31 : 1 with that inf= o (possibly no range-op for .CLZ?), of course it would be wrong to do so. Can you open a bugreport please? Richard. > > /Krister