From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4395 invoked by alias); 24 Mar 2004 18:44:30 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 4228 invoked by alias); 24 Mar 2004 18:44:27 -0000 Date: Wed, 24 Mar 2004 18:44:00 -0000 Message-ID: <20040324184427.4226.qmail@sources.redhat.com> From: "mark at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040318204634.14639.austern@apple.com> References: <20040318204634.14639.austern@apple.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/14639] [3.4/3.5 Regression] [unit-at-a-time] Incorrect emission of unused compiler-generated destructor at -O2 X-Bugzilla-Reason: CC X-SW-Source: 2004-03/txt/msg02964.txt.bz2 List-Id: ------- Additional Comments From mark at codesourcery dot com 2004-03-24 18:44 ------- Subject: Re: [3.4/3.5 Regression] [unit-at-a-time] Incorrect emission of unused compiler-generated destructor at -O2 >>In the test case, the object file should be empty. There are no >>definitions of any functions except for the inline xyz::xyz method, and >>since it is inline it will not be emitted. > > > This happens with the patch I sent earlier. It just removes one of > mark_referenced calls in the C++ backend. There are 4 such calls and I > am unsure if they are actaully needed or not. > I am seeking for testcase exhibiting that mark_referenced at that place > is needed. (I've originally replaced them from the > TREE_SYMBOL_REFERENCED and didn't really checked it without the change). Thanks for your explanation. I agree that it does not make sense for use_thunk to call "mark_referenced" on the function to which the thunk transfers control in the "emit_p == 0" case. That should only happen when the thunk is actually output, i.e, in the "emit_p == 1" case, because in that case the thunk has been directly generated into the assembly file and the function really is needed. (Eventually, it would be better to move that under the control of cgraph, but that is probably too invasive a change right now.) So, if you make that change does it fix the problem? > How much incredible it is? (ie having testcase that exhibits a lot of > unnecesary thunks/vtables would be usefull too). Just take the original test case, but add thousands of classes. That's a very typical situation for some class frameworks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14639