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 0C1C23858D32 for ; Mon, 18 Sep 2023 20:52:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0C1C23858D32 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-01.um.gwdg.de ([134.76.9.216] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1qiLEE-000NnA-Sd; Mon, 18 Sep 2023 22:52:22 +0200 Received: from EXCMBX-29.um.gwdg.de (134.76.9.204) by excmbx-01.um.gwdg.de (134.76.9.216) 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 22:52:22 +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 22:52:22 +0200 Message-ID: <36ac57c1e19b68fd588208a9ac03b58fe29fab32.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 22:52:16 +0200 In-Reply-To: <1dbda88a-60dd-bb00-1217-244d111598fb@free.fr> References: <12c6db0e-10cf-eef6-6209-77da64738897@free.fr> <2cabfda8e4ef48627a681fdb1619f2937cc4bd97.camel@gwdg.de> <1dbda88a-60dd-bb00-1217-244d111598fb@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-14.um.gwdg.de (134.76.9.225) 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 22:15 +0200 schrieb Paul Floyd via Gcc: >=20 > On 18-09-23 21:09, Martin Uecker wrote: >=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? >=20 > My understanding is that this is a generic transformation of >=20 > if (a && b) [which might have been transposed from if (b && a)] >=20 > into >=20 > if (a & b) [with appropriate extension to the right size]. >=20 > That means both get evaluated and we can't take that risk that one of=20 > them traps. Is the problem that valgrind transforms the code before it then emulates it and the problem is that during emulation the code could trap? Martin