From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xmailer.gwdg.de (xmailer.gwdg.de [134.76.10.29]) by sourceware.org (Postfix) with ESMTPS id EDEF13858C2B for ; Mon, 18 Sep 2023 19:09:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDEF13858C2B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de Received: from excmbx-23.um.gwdg.de ([134.76.9.233] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1qiJcy-0009oU-M3; Mon, 18 Sep 2023 21:09:48 +0200 Received: from EXCMBX-29.um.gwdg.de (134.76.9.204) by EXCMBX-23.um.gwdg.de (134.76.9.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.32; Mon, 18 Sep 2023 21:09:48 +0200 Received: from vra-171-103.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.32; Mon, 18 Sep 2023 21:09:48 +0200 Message-ID: <2cabfda8e4ef48627a681fdb1619f2937cc4bd97.camel@gwdg.de> Subject: Re: Safe transposition of logical and operands From: Martin Uecker To: Paul Floyd , "gcc@gcc.gnu.org" Date: Mon, 18 Sep 2023 21:09:47 +0200 In-Reply-To: References: <12c6db0e-10cf-eef6-6209-77da64738897@free.fr> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: excmbx-16.um.gwdg.de (134.76.9.227) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,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: Am Montag, dem 18.09.2023 um 19:56 +0200 schrieb Paul Floyd via Gcc: >=20 > On 18-09-23 16:55, Richard Biener wrote: >=20 > > What you could do is report the access only on the point of use of > > the accessed value? (and disregard when the register holding the > > value is re-used) >=20 > Hi Richard >=20 > Not sure that I follow what you're saying. >=20 > memcheck triggers errors like this at conditional branching opcodes=20 > where it determines that the condition is undefined. >=20 > There are mechanisms to de-duplicate errors, so once an error is emitted= =20 > it won't be printed again. >=20 > However, one of our goals is no false positives. This is one example=20 > that is slipping through the cracks. >=20 I do not understand why memcheck cares about the potential trap when deciding to do the backwards transformation that combines the two comparisons? Can't you just remove this condition? I assume it is meant as a filter to only transform cases which really come from an '&&' condition in the source, but as this example show, this is too strict. Or am I missing something? Martin