From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id B7A443858D32 for ; Mon, 18 Sep 2023 08:00:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B7A443858D32 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-lf1-x12d.google.com with SMTP id 2adb3069b0e04-50078eba7afso6922802e87.0 for ; Mon, 18 Sep 2023 01:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695024016; x=1695628816; 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=yW+H/Vz203sVYTrQ8v4LZaLWAl8VZhRS1WEZjGhnEOs=; b=mCYwwKeVR1IbM2DZjvQlh4G1FiMdJBanvYHdIYDyaUAeyLEBcz/uh7yRrfdw+fIfkG q8qeYQRSnRJ6OSFAJFXE+NdNXLt3kYCJXwB6jA2FE7AySawIDrzZC+vDiDaQuh8GDJoB SyqbRiJqd6YF0gkQDl52y6X62DHVacYZf4/0zp8SELVsp5tx3akt1oTSNF+ZjefF2YVG urgv5BtrJwofyOa8aCzrEHuOdssg3y1guuyTMGySy7tdNhxwxdwI0Oy0/4a0vNfwfd/E 70uqlWM2blHInfWL4AO49oaxKU5UnJYRwr37xFZ/1UyJVko6GosHIKoFsKYSelofafM9 tBUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695024016; x=1695628816; 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=yW+H/Vz203sVYTrQ8v4LZaLWAl8VZhRS1WEZjGhnEOs=; b=hEw6ZQa80dMvvPcWd7TaQGCmiPNyMmdouhbJpspunj/zPg4tZ4rZWudzEmdNEP/2/a iQ67v3PKfbRoxgOZvVav0jJ5bQY9ewnA5jpD/XgtC/LKq7BD/QKh/iSXqwSXPl23qXKU Bs+SVC1jshGr9cSUUs1AeyxFTBabUmSGt6Ci7uL8BAnK+u397o0IhhzInpi7vfqhBL1J NeDBSbm2fDPcLcKTKbiEB6aNv0BgyaYVGTtx1YW1myZg3S7csUdnvMbeyYtZXlut9iZG FGQCLYqZ8vCe9wxopkB6XxzSF0Z0D1uJ9Fjb0rWYCj/vJzQB3xq2NbBtD0VPa9f+Eg6q 7Asg== X-Gm-Message-State: AOJu0YwyzL/9Ac9qETBAEyGaFjRZZedu/DtePtlw5GD4E+nKTLygjuFS vJJ5OjCObV6lPgxahw31tdp/icGdlgq88fl4lRA= X-Google-Smtp-Source: AGHT+IGciPk1Nhg+suCOWd9oQjJq2JpLMMmyJrisZRskqWXhmeNyzlxKK7hXdcmSwJ5ks92HXw2YMf4Wj2go/ma79T4= X-Received: by 2002:ac2:58f2:0:b0:4fb:7c40:9f97 with SMTP id v18-20020ac258f2000000b004fb7c409f97mr6405265lfo.27.1695024015937; Mon, 18 Sep 2023 01:00:15 -0700 (PDT) MIME-Version: 1.0 References: <12c6db0e-10cf-eef6-6209-77da64738897@free.fr> In-Reply-To: From: Richard Biener Date: Mon, 18 Sep 2023 10:00:03 +0200 Message-ID: Subject: Re: Safe transposition of logical and operands To: Jonathan Wakely Cc: Paul Floyd , "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 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 Mon, Sep 18, 2023 at 9:24=E2=80=AFAM Jonathan Wakely via Gcc wrote: > > On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, wrote: > > > > > > > On 17-09-23 22:51, Jonathan Wakely wrote: > > > > > > > > Why would it be trapping? It's loading an int64_t, which might be > > > uninitialised but it can't trap. > > > > In this context I think that Valgrind is considering that any memory > > load could trap. > > > > There are no padding bits in int64_t and all object representations are > valid values, so it has no trap representations. > > > > > > *f on a std::optional is not like dereferencing a pointer, the int64_= t > > > memory location is always present as part of the object. > > > > For this > > > > movq 40(%rbx), %rax > > > > unless you know that what RBX+40 is pointing to is safe to dereference > > it's not different to dereferencing a pointer. > > > > If it isn't safe to load that integer then it isn't safe to call f.operat= or > bool() either. GCC knows they are part of the same object. > > > > So I think that the problem is that Valgrind is being cautious and not > > allowing any loads but GCC is accepting what it considers safe loads > > from the stack. > > > > Yes, GCC assumes that the reference is bound to a valid object, because C= ++ > requires that to be true. Of course memcheck can't assume that, because o= ne > of its main reasons to exist is to find undefined behaviour where that > isn't true! > > I think what GCC is doing is a valid transformation, in the context of a > valid C++ program. But I'm not sure that helps valgrind, which doesn't ha= ve > the liberty of assuming a valid program. More specifically GCC thinks it's fine to speculate loads (given it can pro= ve doing so doesn't trap) Richard.