From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19593 invoked by alias); 24 Mar 2004 18:23:14 -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 19543 invoked by alias); 24 Mar 2004 18:23:12 -0000 Date: Wed, 24 Mar 2004 18:23:00 -0000 Message-ID: <20040324182312.19542.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/msg02957.txt.bz2 List-Id: ------- Additional Comments From hubicka at ucw dot cz 2004-03-24 18:22 ------- 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-23 21:25 ------- > Subject: Re: [3.4/3.5 Regression] [unit-at-a-time] Incorrect > emission of unused compiler-generated destructor at -O2 > > > >I am trying to look into it, but I am not able to figure out testcase > >where the patch above fails. It should have function that is referenced > >by thunk. Additionally the thunk needs to be output but the function > >itself does not (if there wasn't the reference from the thunk). In that > >case I would expect us to fail to see the dependency in between thunk > >and function and not output it at all with the patch applied. > > > >Do you have idea how such testcase shall look like? I am really not > >very faimiliar with these details of C++ implementation making it > >somewhat dificult to track this down resonably. > > > > > There are three kinds of entities in play: > > (1) Vtables > > (2) Virtual functions > > (3) Thunks > > A vtable is an array, containing pointers to either virtual functions or > thunks. Thunks are little stubs that reference a virtual function. A > virtual function and its associated thunks are always emitted together. > > Are you sure this is a problem with thunks and not with vtables? Yes. The way cgraph code works is giving cgraph_finalize_function/cgraph_finalize_variable calls that adds function/variable into cgraph datastructure. It is not directly output to file as we used to do, instead cgraph decide when it is good time to do so (at the end of compilation for unit-at-a-time or immediately in most cases for non-unit-at-a-time) and if do it at all. Both vtables and functions are not output until they are needed (either externally visiable or referenced by some datastructure or function that is already needed). Problem with thunks is that they go on side and they are neither functions nor variables. The old code contained several TREE_SYMBOL_REFERENCED(...)=1 calls that are now replaced by mark_referenced (...) calls that makes cgraph code to believe that the functions/vtables are referenced by some already output assembly and thus they get scheduled to be output as well unconditionally. > > 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). > > I expect that the bug is that cgraph is incorrectly deciding to emit a > vtable. Having decided that, you are emitting everything else because > it is pointed to from the vtable. It goes by C++ frontend deciding to emit vtable in C++ frontend notion (so it is delayed until needed by cgraph), this makes C++ frontend to mark_used the thunk in the vtable that in turn makes mark_referenced the function and cgraph code gets fooled. We simply need to figure way to do the trick without using mark_referenced bit and instead making the dependency obvious to cgraph. The thunks are referenced only by vtables, right? Perhaps the thunks should not be mark_used at all during the C++ frontend is looking for used thinks and we can go directly to the thunked functions. Later we can we can catch it inside mark_referenced via C++ hook that will mark_used the thunk. That way we will again output only thunks that are referenced by vtables that are output to assembly file. At the moment cgraph code works by actually outputting all global variables until all needed functions are known, so such patch would work for 3.4. For 3.5 I would preffer to reorganize things in a way so variables are output very last so we can take into account the scenarios where variable used to be reachable but optimizers elliminated all references to it. But for 3.5 we may want to get the multiple entry points working too. > > The way to solve this problem is to figure out what thing you are > deciding to output first. Since the object file should be entirely > empty, outputting anything at all is a bug. > > I've retargeted this at 3.4.0, as not solving this will cause incredible > amounts of code bloat for C++ applications. How much incredible it is? (ie having testcase that exhibits a lot of unnecesary thunks/vtables would be usefull too). Honza > > > > -- > > > 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