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

["jh at suse dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jh at suse dot cz  2004-03-23 09:52 -------
Subject: Re:  New: Incorrect emission of unused compiler-generated destructor at -O2

> >So when the function itself gets marked as necesary we automatically
> >emit the thunk when the mark_used_thunk has been called, right?
> 
> Yes.  Whenever a function is emittted, so are all of its associated thunks.
> 
> >I guess we need two thinks - we need to manage that once we discover
> >thunk to be necesary we need to mark the function it is refering to and
> >we need to emit thunks iff they are really reachable (not just used,
> >right)?
> 
> Yes.
> 
> >It would be ideal if the thunk was behaving like ordinary function, but
> >for some reason it is not.  Is there way to recognize thunk in C++
> >independent way?
> 
> No.  But, you could always change things so that was possible, I 
> suppose.  Thunks cannot be represented as ordinary functions until we 
> have multiple entry points, and we don't yet have that.
> 
> >I guess we will need kind of hooks - tell cgraph code that given decl is
> >thunk and thunk is like function but not quite as it has no body and
> >reffers to other function and it is not necesay to assemble it as it
> >gets assembled magically with the function body.
> 
> Yes.
> 
> >Hmm, perhaps I am getting overzelaous here (hope so).  I am not quite
> >sure how emit_p works. When the emit_p is set?  If it is at function
> >expansion time, it is too late - we need to be finished this in advance.
> 
> emit_p is set from emit_associated_thunks, which is called for a 
> function's thunks right before the function itself is sent to 
> tree_rest_of_compilation.

Mark,
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.

Thanks,
Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14639