From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B63EF3858D3C for ; Mon, 27 Feb 2023 20:03:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B63EF3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677528187; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=3+tdHPBl9TcKB1eqpWbhovpXQU7NT0OgLFV9UUwfJmw=; b=bjWVXZ8TOkUr6/JspFmnynOcp3K3MiYVIgMZjnXZi3fdTx++ywZ+QQeysjkwdktw0l+OO2 TctrgxhQxp+/WC1v24X70jVYXJZ6FAvNIGyH9XoXRBYYMGyQW5HeslDXMVQlWn9ENxllvV aZvAn8JUf6mZ2IJVh4aVMKUw4BOKuSQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-93-vx5Osu8iMKKuw-zqS5SUyw-1; Mon, 27 Feb 2023 15:03:01 -0500 X-MC-Unique: vx5Osu8iMKKuw-zqS5SUyw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3CAF629AB3EF; Mon, 27 Feb 2023 20:03:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.101]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E365E2166B2B; Mon, 27 Feb 2023 20:03:00 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 31RK2v7b967100 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 27 Feb 2023 21:02:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31RK2utn967099; Mon, 27 Feb 2023 21:02:56 +0100 Date: Mon, 27 Feb 2023 21:02:56 +0100 From: Jakub Jelinek To: Richard Biener , gcc-patches@gcc.gnu.org, Segher Boessenkool , richard.sandiford@arm.com Subject: Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803] Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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, Feb 27, 2023 at 07:51:21PM +0000, Richard Sandiford wrote: > I think RTL and gimple are different in that respect. > SHIFT_COUNT_TRUNCATED's effect on shifts is IMO a bit like > CTZ_DEFINED_VALUE_AT_ZERO's effect on CTZ: it enumerates common > target-specific behaviour, but doesn't turn invalid/should-not-be-evaluated > values into valid values. Not defining SHIFT_COUNT_TRUNCATED is like > defining CTZ_DEFINED_VALUE_AT_ZERO to 0. > > The docs say: > > Note that regardless of this macro the ``definedness'' of @code{clz} > and @code{ctz} at zero do @emph{not} extend to the builtin functions > visible to the user. Thus one may be free to adjust the value at will > to match the target expansion of these operations without fear of > breaking the API@. > > So for CTZ this really is an RTL thing, which can leak into gimple > through ifns. I'd argue that the same is true for SHIFT_COUNT_TRUNCATED > and conditional shifts like COND_SHL: normal gimple shifts aren't guaranteed > to honour SHIFT_COUNT_TRUNCATED, but COND_SHL should be. I understand that if SHIFT_COUNT_TRUNCATED 1 is defined, then formerly out of bounds shift is well defined on RTL. after all, for SHIFT_COUNT_TRUNCATED the generic code removes shift count masking as redundant, so code without UB in the source could otherwise appear to have UB on RTL. The question is what happens with SHIFT_COUNT_TRUNCATED 0 or C?Z_DEFINED_VALUE_AT_ZERO 0, if encountering the RTL with invalid operand(s) is undefined behavior, or simply undefined value but no other side-effects. There are many RTL expressions which invoke on invalid values really undefined behavior, it can crash the program etc. The question is if out of bounds shifts are like that too or not. Ditto for CLZ/CTZ. Jakub