From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9815 invoked by alias); 26 Mar 2004 10:01:44 -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 9721 invoked by alias); 26 Mar 2004 10:01:42 -0000 Date: Fri, 26 Mar 2004 10:01:00 -0000 Message-ID: <20040326100142.9720.qmail@sources.redhat.com> From: "hubicka at ucw dot cz" 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/msg03095.txt.bz2 List-Id: ------- Additional Comments From hubicka at ucw dot cz 2004-03-26 10:01 ------- Subject: Re: [3.4/3.5 Regression] [unit-at-a-time] Incorrect emission of unused compiler-generated destructor at -O2 > > ------- Additional Comments From mark at codesourcery dot com 2004-03-26 08:23 ------- > Subject: Re: [3.4/3.5 Regression] [unit-at-a-time] Incorrect > emission of unused compiler-generated destructor at -O2 > > hubicka at ucw dot cz wrote: > > > It will fix the problem because the thunk is only output at the time > > function is assembled. But it will make mark_referenced useless anyway > > as when the function is assembled it is already mark_reference-d. > > Removing the call as done by my patch should be fine then, but we must > > ensure that referencing the vtable that references the thunk makes > > cgraph code notice that the function referenced by the thunk is > > referenced too, so the dependencies goes right. I am not quite sure how > > to construct testcase, but I will try to dig into it. Obviously the > > testsuite works so it seems to be fine in majority of case but my > > experience is that there are common dead ends not covered by testsuite > > in these areas, so I still feel unsafe about that patch, but all my > > attempts to construct testcase seems to be failing. > > I am not sure that the case you are worried about can happen. > > For that to happen, there would have to be a vtable that contains a > reference to a thunk, but no references to the function to which the > thunk refers. The only way a thunk to C::f can occur is in a vtable for > C, or a base subobject of C. But, in that case, C::f will also be > referenced directly from the vtable. > > >>>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. > > > > > > We obvisouly emit unnecesary thunks, lets see what we can do about this. > > I tried to compile mozilla with the patch fixing the testcase and > > measured no difference in code size tought... > > Many of the "unncessary" thunks are required by the ABI. The ABI > guarantees that all thunks are put out with the function to which they > transfer control. > > Based on our discussion, I think your patch is OK. Please check it in, > but remove the call to mark_referenced copmletely, rather than > commenting it out. OK, thanks! I will try to investigate the remaining 3 calls if they can cause similar showstopper too. Honza > > Thanks, > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14639 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14639