From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30530 invoked by alias); 21 Mar 2004 19:25:05 -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 30474 invoked from network); 21 Mar 2004 19:25:03 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.6) by sources.redhat.com with SMTP; 21 Mar 2004 19:25:03 -0000 Received: (qmail 19710 invoked from network); 21 Mar 2004 19:25:02 -0000 Received: from 227.148-60-66-fuji-dsl.static.surewest.net (HELO codesourcery.com) (mitchell@66.60.148.227) by mail.codesourcery.com with SMTP; 21 Mar 2004 19:25:02 -0000 Message-ID: <405DEC11.7030008@codesourcery.com> Date: Sun, 21 Mar 2004 19:25:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Jan Hubicka CC: austern at apple dot com , gcc-bugs@gcc.gnu.org Subject: Re: [Bug c++/14639] New: Incorrect emission of unused compiler-generated destructor at -O2 References: <20040318204634.14639.austern@apple.com> <20040321182619.GA28573@atrey.karlin.mff.cuni.cz> In-Reply-To: <20040321182619.GA28573@atrey.karlin.mff.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg02576.txt.bz2 List-Id: Jan Hubicka wrote: >>Consider the following file: >>class AAA { >>public: >> virtual ~AAA(); >>}; >> >>class BBB { >>public: >> virtual ~BBB(); >>}; >> >>class xyz : public AAA, public BBB { >>public: >> xyz() : AAA(), BBB() { } >>}; >> >> >> >> >>Class xyz has no key method, so its vtable should be emitted only in translation units where it's used. >>With "gcc -O0 -c foo.cc" I get what I expect: the compiler doesn't emit _ZTV3xyz, _ZN3xyzD0Ev, or >>anything else. With "gcc -O2 -c foo.cc" I get incorrect behavior: the compiler emits xyz's destructor >>and vtable, thunks, and all of the things in AAA and BBB that are required to support them. >> >>This is a regression. In 3.2.2, O0 and O2 both behave correctly. >> >> > >This can be avoided by disabling following mark_referenced call: > >Index: cp/method.c >=================================================================== >RCS file: /cvs/gcc/gcc/gcc/cp/method.c,v >retrieving revision 1.279 >diff -c -3 -p -r1.279 method.c >*** cp/method.c 12 Mar 2004 17:09:01 -0000 1.279 >--- cp/method.c 20 Mar 2004 15:27:33 -0000 >*************** use_thunk (tree thunk_fndecl, bool emit_ >*** 359,365 **** > this translation unit. */ > TREE_ADDRESSABLE (function) = 1; > mark_used (function); >! mark_referenced (DECL_ASSEMBLER_NAME (function)); > if (!emit_p) > return; > >--- 359,365 ---- > this translation unit. */ > TREE_ADDRESSABLE (function) = 1; > mark_used (function); >! /*mark_referenced (DECL_ASSEMBLER_NAME (function));*/ > if (!emit_p) > return; > >The problem is that C++ frotnend manages thunks "on the side" and does >not show to backend what DECLs will be used by thunks and what thunks >will be emit. This is dealt with handling the depenedencies >conservativly. This line comes from replacing DECL_REFERENCED.* = 1 by >mark_referenced call so I am not quite sure it is still necesary >(testsuite passes without this line). > >However we likely need some way to explain backend the hidden >dependencies. Would it be possible to explain me why exactly the thunk >needs to be output and what DECLs will it reference? >(I know that the thunks are associated to functions and are output at >the same time the function is output and they become needed by >use_thunk, but this all can be overly conservative now) > > Every thunk references exactly one function. The thunk is just a little stub that adjusts one incoming parameter, and then transfers control to the referenced function. From a FUNCTION_DECL, you can look at DECL_THUNKS to find all of its thunks. From a thunk, you can look at THUNK_TARGET to find the function to which it transfers control. It does make sense to me that we call mark_referenced in the case that emit_p is zero. If emit_p is 1, that does make sense. In the emit_p == 0 case, we should wait to emit the thunk until we know that we need to emit the vtable referencing it, which is what we used to do. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com