From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 4989D3858D32 for ; Sun, 17 Sep 2023 20:51:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4989D3858D32 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-ej1-x62a.google.com with SMTP id a640c23a62f3a-9ada2e6e75fso506637866b.2 for ; Sun, 17 Sep 2023 13:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694983883; x=1695588683; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=e1r/tTOKf/pM0qHWb1Gibp6OVLwNk1YA0WfjRpSNFa4=; b=KboygqYcQKi6xg/i2DtuKjTX7bpA2Zk9qvmCAxXf1hpiIuoaJtuToO2Xs+SQFU9Lt4 rQyusoHBsregoBhpVKxo/D50K9HLOybT9JMuOyRiZsyhMB1ps9s2XMZRVWlMrBOBNZej G7ep0pOqF2f/RjB19tZz9/5Jxoae7lavslL2feWOfS+4/eLrpd70tOZOkm1TRVKObdrm X7Wsq2J3jBEXe4UPxM2jfKds/Hh7EscFEzqKU0u2tkQmN1u3frD/2mc0oAseGbLLsZmf Dm1LeW6r8fOPM+qQmWcCOmhFn2fFgWs3G+IboA0BZ2f4myAO65UDvKuYeYYxUeU9AoFi DTeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694983883; x=1695588683; h=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=e1r/tTOKf/pM0qHWb1Gibp6OVLwNk1YA0WfjRpSNFa4=; b=rePAzJhl99KvzIZqT0+DXMaubhG3OMfgCVKDeDyG8iHikceTuy2WVisuYjil41cbOw 0tkmlj/NCRFOG7QoLfEeQvZhSvIEEr2zXp5unnGf2xqbYcXyqyEE588iX901+b+TaP9K L3nbQ9RVZKzz9fHmOpUN12WQYWA/AS7mRsskMleY8cc7qhr+UmzsAaH0Pcctnk48h2rR +W3I8d4YyCjIdp5mRl0qVqeZyOZyi3KNWWfvXmJMNwNFJ3kLEuNwULsWwKeiHNhGC/p2 bmgJCi86ol+Z0vMdBl2Jf6KRullH0T3KqOqs5B7FYyP6eEQx0J+frG5VKybmolwPkhja fqqg== X-Gm-Message-State: AOJu0YyJvBpDZ908QViIkH55dUgRmrOhM8lfQLdieWICmWeYLPwtogkM Ht9TWXFJVJnv+vTO5eVdTMga4hUQEcOYBfIchn8= X-Google-Smtp-Source: AGHT+IGs+3VWhPQeTEwJdyy/MERK+Imehw7vQu7PV+f5xXo5w86QrsdpWPpMLL5eDiY8gTvBstQ92sHoJpg8clvAkBI= X-Received: by 2002:a17:906:104e:b0:9ad:e489:8c98 with SMTP id j14-20020a170906104e00b009ade4898c98mr4498150ejj.6.1694983882700; Sun, 17 Sep 2023 13:51:22 -0700 (PDT) MIME-Version: 1.0 References: <12c6db0e-10cf-eef6-6209-77da64738897@free.fr> In-Reply-To: <12c6db0e-10cf-eef6-6209-77da64738897@free.fr> From: Jonathan Wakely Date: Sun, 17 Sep 2023 21:51:11 +0100 Message-ID: Subject: Re: Safe transposition of logical and operands To: Paul Floyd Cc: "gcc@gcc.gnu.org" Content-Type: multipart/alternative; boundary="0000000000003a7d98060594304c" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,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: --0000000000003a7d98060594304c Content-Type: text/plain; charset="UTF-8" On Sun, 17 Sept 2023, 20:33 Paul Floyd via Gcc, wrote: > Hi > > I'm looking at a Valgrind issue. Full details here > > https://bugs.kde.org/show_bug.cgi?id=472329 > > This code > > void foo(std::optional f) { > std::cout << (f ? *f : 0) << std::endl; > std::set test; > test.emplace(0); > auto it{test.begin()}; > while (it != test.end()) { > int64_t b{*it}; > // Valgrind error on next line > if (f && *f != b) { > [snip] > > int main() { foo(std::nullopt); } > > generates (using g++ 12.2 on FreeBSD 13.2 amd64) > > movq 40(%rbx), %rax > Error on next line: > cmpq %r14, %rax # f, SR.252 > je .L47 > cmpb $0, -97(%rbp) #, %sfp > jne .L69 > > Unless I'm completely mistaken cmpq %r14, %rax is the quadword > comparison of *f != b and cmpb $0, -97(%rbp) is the > std::optional::operator bool() comparison with 0. That means that g++ > has transposed the order of evaluation. > > > The first cmpq/je generates a > > ==49599== Conditional jump or move depends on uninitialised value(s) > > Valgrind has machinery to detect transformations like this and to > convert them back into bit accurate bitwise ands. > > However, Valgrind thinks that these transpositions can't be done when > there are potentially trapping memory loads like *f. > Why would it be trapping? It's loading an int64_t, which might be uninitialised but it can't trap. *f on a std::optional is not like dereferencing a pointer, the int64_t memory location is always present as part of the object. > So who is right? Is this a safe transformation? > > Regards > Paul > --0000000000003a7d98060594304c--