From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id 536843858D28 for ; Mon, 11 Dec 2023 19:17:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 536843858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 536843858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702322259; cv=none; b=UQLXS2ZobgZUe+aM7lkqpThF4h9Ao2DtpfjgzX/6VVGS1bWvFckldW12Vt7HPIbWfkWSo+kOfxabJdreYK1PL9OyxlCh9ln+2RnU5eovfnmJm4GzyZXcXKHW417TxTUcLufdAE3EVh7ImcPjg8Ey0AJzQzwaV1DlQXdhTof8X8o= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702322259; c=relaxed/simple; bh=Md+//raBsKFVOraCza4Spj2xR0pmFf+bSjnNwxceh1Y=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:From: Mime-Version:Subject:Date:Message-Id:To; b=qVNQljSlgZNi5yve9dlCP/64YL6bS4TpVFN97MdAijmZAZ8NZJ5qyvgpLAXGcr9BnrSHQxRxy74D5sEJizFRlmjm27XA+UcJ0uAIpXhfhra9I0dVRtaLBrbAW21lBi3Ot4dBDu4bYnI3hz85eirj0jNK2FXZ62mL0T2xAgHG8aI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3EDB021EEF; Mon, 11 Dec 2023 19:17:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1702322257; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C1bUFDh8hY6AqEX29BE3Y/IO3mHva1N3zCdHlPZvBwY=; b=fwk7MQP0uDNTmRHZ7+SYmWF/5xB11wnrmA3Xo/cGEq6hFrY8EQGkFvn4lYuozWdejfZoPe MgwcZ9Km0tqbQx6J/+rPf/V5/Vh1SYcOemzGxVfsSvizSMSXFzx1d7rfBku1vbyF44ZG3e mFzgcu2boJAIkkJC7Tcy4zLrKb53QGM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1702322257; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C1bUFDh8hY6AqEX29BE3Y/IO3mHva1N3zCdHlPZvBwY=; b=7rbWyVUd1XWYScw7Vss7As2VKwykv2h24mjK6r0g0vj7VvLurs2CMOXuF9vMlxxpjTXkhu X5AntCIIkvrAUBCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1702322257; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C1bUFDh8hY6AqEX29BE3Y/IO3mHva1N3zCdHlPZvBwY=; b=fwk7MQP0uDNTmRHZ7+SYmWF/5xB11wnrmA3Xo/cGEq6hFrY8EQGkFvn4lYuozWdejfZoPe MgwcZ9Km0tqbQx6J/+rPf/V5/Vh1SYcOemzGxVfsSvizSMSXFzx1d7rfBku1vbyF44ZG3e mFzgcu2boJAIkkJC7Tcy4zLrKb53QGM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1702322257; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C1bUFDh8hY6AqEX29BE3Y/IO3mHva1N3zCdHlPZvBwY=; b=7rbWyVUd1XWYScw7Vss7As2VKwykv2h24mjK6r0g0vj7VvLurs2CMOXuF9vMlxxpjTXkhu X5AntCIIkvrAUBCw== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 208FD134B0; Mon, 11 Dec 2023 19:17:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap2.dmz-prg2.suse.org with ESMTPSA id 82PtB1Fgd2UmNwAAn2gu4w (envelope-from ); Mon, 11 Dec 2023 19:17:37 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] c++: End lifetime of objects in constexpr after destructor call [PR71093] Date: Mon, 11 Dec 2023 20:17:22 +0100 Message-Id: <5095B3D3-E545-4827-82BB-F7FD321F0225@suse.de> References: Cc: Nathaniel Shead , gcc-patches@gcc.gnu.org In-Reply-To: To: Jason Merrill X-Mailer: iPhone Mail (21B101) X-Spam-Level: X-Spam-Score: -3.80 Authentication-Results: smtp-out1.suse.de; none X-Spam-Level: X-Spam-Score: -3.80 X-Spamd-Result: default: False [-3.80 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; BAYES_HAM(-3.00)[100.00%]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gmail.com,gcc.gnu.org]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spam-Flag: NO X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 11.12.2023 um 20:12 schrieb Jason Merrill : >=20 > =EF=BB=BFOn 12/11/23 03:02, Richard Biener wrote: >>> On Sun, 10 Dec 2023, Jason Merrill wrote: >>> On 12/10/23 05:22, Richard Biener wrote: >>>>> Am 09.12.2023 um 21:13 schrieb Jason Merrill : >>>>>=20 >>>>> =EF=BB=BFOn 11/2/23 21:18, Nathaniel Shead wrote: >>>>>> Bootstrapped and regtested on x86-64_pc_linux_gnu. >>>>>> I'm not entirely sure if the change I made to have destructors clobbe= r >>>>>> with >>>>>> CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seem= ed to >>>>>> have >>>>>> broken by doing this and I wasn't able to find anything else that rea= lly >>>>>> depended on this distinction other than a warning pass. Otherwise I c= ould >>>>>> experiment with a new clobber kind for destructor calls. >>>>>=20 >>>>> It seems wrong to me: CLOBBER_EOL is documented to mean that the stora= ge is >>>>> expiring at that point as well, which a (pseudo-)destructor does not i= mply; >>>>> it's perfectly valid to destroy an object and then create another in t= he >>>>> same storage. >>>>>=20 >>>>> We probably do want another clobber kind for end of object lifetime. A= nd/or >>>>> one for beginning of object lifetime. >>>>=20 >>>> There?s not much semantically different between UNDEF and end of object= but >>>> not storage lifetime? At least for what middle-end optimizations do. >>>=20 >>> That's fine for the middle-end, but Nathaniel's patch wants to distingui= sh >>> between the clobbers at beginning and end of object lifetime in order to= >>> diagnose stores to an out-of-lifetime object in constexpr evaluation. >> Ah, I see. I did want to add CLOBBER_SOL (start-of-life) when working >> on PR90348, but I always fail to finish working on that stack-slot sharin= g >> issue. But it would be for the storage life, not object life, also >> added by gimplification. >>> One option might be to remove the clobber at the beginning of the constr= uctor; >>> are there any useful optimizations enabled by that, or is it just pedant= ically >>> breaking people's code? >> It's allowing DSE to the object that was live before the new one. Not >> all objects require explicit destruction (which would get you a clobber) >> before storage can be re-used. >>>> EOL is used by stack slot sharing and that operates on the underlying >>>> storage, not individual objects live in it. >>>=20 >>> I wonder about changing the name to EOS (end of storage [duration]) to a= void >>> similar confusion with object lifetime? >> EOS{L,D}? But sure, better names (and documentation) are appreciated. >=20 > Maybe something like this? Or shall we write out the names like CLOBBER_O= BJECT_START, CLOBBER_STORAGE_END, etc? Yeah, the abbreviations look a bit confusing so spelling it out would be bet= ter Richard=20 >=20 > <0001-tree-add-to-clobber_kind.patch>