[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 23:51 -------
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-24 18:44 -------
> Subject: Re:  [3.4/3.5 Regression] [unit-at-a-time] Incorrect
>  emission of unused compiler-generated destructor at -O2
> 
> >>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).
> 
> Thanks for your explanation.
> 
> I agree that it does not make sense for use_thunk to call 
> "mark_referenced" on the function to which the thunk transfers control 
> in the "emit_p == 0" case.
> 
> That should only happen when the thunk is actually output, i.e, in the 
> "emit_p == 1" case, because in that case the thunk has been directly 
> generated into the assembly file and the function really is needed. 
> (Eventually, it would be better to move that under the control of 
> cgraph, but that is probably too invasive a change right now.)
> 
> So, if you make that change does it fix the problem?

It will fix the problem because the thunk is only output at the time
function is assembled.  But it will make mark_referenced useless anyway
as when the function is assembled it is already mark_reference-d.
Removing the call as done by my patch should be fine then, but we must
ensure that referencing the vtable that references the thunk makes
cgraph code notice that the function referenced by the thunk is
referenced too, so the dependencies goes right.  I am not quite sure how
to construct testcase, but I will try to dig into it.  Obviously the
testsuite works so it seems to be fine in majority of case but my
experience is that there are common dead ends not covered by testsuite
in these areas, so I still feel unsafe about that patch, but all my
attempts to construct testcase seems to be failing.
> 
> > How much incredible it is?  (ie having testcase that exhibits a lot of
> > unnecesary thunks/vtables would be usefull too). 
> 
> Just take the original test case, but add thousands of classes.  That's 
> a very typical situation for some class frameworks.

We obvisouly emit unnecesary thunks, lets see what we can do about this.
I tried to compile mozilla with the patch fixing the testcase and
measured no difference in code size tought...

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