[Bug c++/14639] [3.4/3.5 Regression] [unit-at-a-time] Incorrect emission of unused compiler-generated destructor at -O2

["hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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