From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 2799D3857C4A; Wed,  6 Mar 2024 16:14:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2799D3857C4A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709741699;
	bh=G/N32wsX6676Z7X28HiV+sPeQlqeQE/68Zl8Ni1c9JY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=k0Tc5hlsInVoEo6ZM10ajgY971ukuFl/+QBA9537dwuhAQwWFVG2Okuc7DVFVv9Pu
	 ML3z3obMMYQWCC9b7ygjp8fifvhNwNXGWQ2md6mGS88ipuvVyi9uQNKWo4H5StvTvB
	 /Xsso6pP9+8KQl2hngP/FgO2Qgw81rSrrExlC0aA=
From: "mwinkler at blizzard dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/114245] Defaulted virtual destructors that do no work
 overwrite the vtable with `-O0`
Date: Wed, 06 Mar 2024 16:14:58 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mwinkler at blizzard dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114245-4-GpVx6dpL8I@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114245-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114245-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114245

--- Comment #3 from Max Enrico Winkler <mwinkler at blizzard dot com> ---
> Yes this sounds like you are runing into what I have described as being u=
ndefined behavior.

Understood and agreed.

However this specific example is an object that effectively does no work on
destruction.
We would expect the object to be embedded in the binary and not rely on sta=
tic
de-init order since there should be nothing running during destruction.

With `-O2` the vtable writes get dead store removed and the destructor ends=
 up
being a full nop as expected.

Clang and MSVC have this behaviour and clang also provides more control with
the `no_destroy` attribute.

In general we didn't expect to have static de-init issues with an object of
this type since we didn't expect anything to be running during destruction.

We are aware of the various ways to work around static [de]-init issues but=
 I
ultimately think GCC just shouldn't be overwriting vtables on destruction h=
ere.

If you guys think otherwise no worries we can work-around it.=