From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C045D3858425; Wed, 6 Mar 2024 16:33:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C045D3858425 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709742796; bh=Sj3tRLbprvy9ges5ySmuLglNAzsRn3+02RqmWv4jODs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QMWMa5rrsBY0OG28yv/wSV8hQxuoIUmCX/tUX5iCeZa059eiq6rKSoSiavZ+bca9Y xjS/SPrJVgcriekdomtDq/8gVA3eKX3k5otBw7XTkl4P/ckc2BpPVOYNf144tca+O4 bEKAazYLq2X2+KEkIHKp/zfjse6DkFQ1q0KXp2eY= From: "redi at gcc dot 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:33:16 +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: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org 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: keywords Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114245 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization --- Comment #4 from Jonathan Wakely --- Updating the vtable is necessary during destruction if a later (i.e. less derived) destructor calls a virtual function. But if we can tell that the current dtor and all later base dtors are trivial, then we know that can't happen. If the front end detected that case, we wouldn't need to rely on dead store elimination. Maybe we could even avoid the __cxa_atexit registration if the most derived dtor is trivial (I don't recall if there's some ABI reason we need that registration even if the dtor is known to be a no-op). That is something th= at that would be much harder for the middle end to do, so is an argument for t= he front end handling it. If we are allowed to remove the __cxa_atexit call, that changes this from "remove some dead stores even at -O0 which helps some programs with UB" to a more significant optimization.=