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 021DE3858401 for ; Wed, 3 Apr 2024 16:42:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 021DE3858401 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 021DE3858401 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712162545; cv=none; b=HBseYG2TjOh0MjXdKehDZNXP9NFNQelmqDMfJ8KdMWOQRzqM2cGyJf4aKdmXGIaQM6gzxMmSfjqBRg/J/aZ5fgLhUsfsGU/H5pfopqKKfYW5J6YT+OFdHqmus00m3mI7w8adUkq2owHakMkxA5EHzwKWjKdVKv9PBHvd6V9sjxA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712162545; c=relaxed/simple; bh=oIH619xAtumcyF9XNLNTAM6xw+/G/fJoqKvfxw57bfc=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=FwBasx+WadYykfJ3gEi2nYCe17zyrIQVmLfQM4r5ady+aA14kKi4FFXpBEblR+djNELVw1k6/xh6CsOHBO+mFbQ9JZpLNz+4BGflJJdot9eDsed1K10BsQqqQbM7DbiGzLlhvLqZRkyk0iEgVlPmaQUhR8ma04fKbxSRtfJ+YlY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712162543; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=eYiWi5Km2yUg5voZR7x8bYASze8Is+gAOR7lqQtwTWM=; b=PmVpAdEDv8YcPEXREn87KyzIMNfnB9xws8qLPeUAAjIpryeiNikupoddCxO84UQvjQGeFD PC3tXKQdyvL/sXepx4l7Cpk8QzNAxLP4qxpuDm3a3/aGcQL2J7u1vFijujO8M+ttmFJDEw AgOLCGqhYjio5OMKZ12YhBsfYuvPymk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-571-_IRvv1rqP-abzn8MrJng1w-1; Wed, 03 Apr 2024 12:42:20 -0400 X-MC-Unique: _IRvv1rqP-abzn8MrJng1w-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3CDC6101A530 for ; Wed, 3 Apr 2024 16:42:20 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 03487492BD1; Wed, 3 Apr 2024 16:42:19 +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 433GgEsg1879530 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 3 Apr 2024 18:42:14 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 433GgEGp1879529; Wed, 3 Apr 2024 18:42:14 +0200 Date: Wed, 3 Apr 2024 18:42:13 +0200 From: Jakub Jelinek To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: Implement C++26 P2809R3 - Trivial infinite loops are not Undefined Behavior Message-ID: Reply-To: Jakub Jelinek References: <8166752c-6ad7-4b56-a451-da614234e47f@redhat.com> MIME-Version: 1.0 In-Reply-To: <8166752c-6ad7-4b56-a451-da614234e47f@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 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.4 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_H4,RCVD_IN_MSPIKE_WL,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 Wed, Apr 03, 2024 at 12:07:48PM -0400, Jason Merrill wrote: > Using std::is_constant_evaluated directly in a loop condition is, as the > paper says, unlikely and "horrendous code", so I'm not concerned about > surprising effects, though I guess we should check for it with > maybe_warn_for_constant_evaluated. Ok, though guess the question is what to say about it. Because unlike the existing cases in maybe_warn_for_constant_evaluated where it always evaluates to true or always to false depending on where, in the trivial empty iteration statements it evaluates to always true or always false depending or sometimes true, sometimes false, depending on if the condition is a constant expression that evaluates to true (then it is always true), or if in immediate function (also always true), or if not in constexpr function (then always false), or in constexpr function (then it might be true or false). Not sure how exactly to word that. Maybe just say that it is horrendous code to use std::is_constant_evaluated () in trivial empty iteration statement conditions ;) What about loops with non-empty bodies or other reasons why they aren't trivial empty iteration statements? Shall we do maybe_warn_for_constant_evaluated for those (with the current wording, false in non-constexpr fn, true in consteval)? > > So, the patch below attempts to discover trivially empty iteration > > statements at cp_fold time if it is the final mce_false folding, > > attempts to maybe_constant_value with mce_false evaluate the conditions > > and replaces it with the returned value if constant non-zero. > > Please refactor this code to share most of the implementation between the > loop types. Will do. Jakub