[Bug c++/14639] New: Incorrect emission of unused compiler-generated destructor at -O2

Jan Hubicka jh@suse.cz
Mon Mar 22 09:44:00 GMT 2004


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

OK, that was my original understanding but somehow I got to impression
that it is more complex.
So when the function itself gets marked as necesary we automatically
emit the thunk when the mark_used_thunk has been called, right?
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)?

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?

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.  This is quite nasty (I
really don't want to introduce new kind of function - we already have
way too many of them), but does it at least sound right to you?
> 
> 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.
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.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com



More information about the Gcc-bugs mailing list