[Bug c++/13768] [3.4/3.5 Regression] -funit-at-a-time compiles unused inline function

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

------- Additional Comments From jh at suse dot cz  2004-02-03 15:59 -------
Subject: Re:  [3.4/3.5 Regression] -funit-at-a-time compiles unused inline function

> 
> ------- Additional Comments From jh at suse dot cz  2004-02-03 15:53 -------
> Subject: Re:  [3.4/3.5 Regression] -funit-at-a-time compiles unused inline function
> 
> > 
> > ------- Additional Comments From mark at codesourcery dot com  2004-02-03 15:46 -------
> > Subject: Re:  [3.4/3.5 Regression] -funit-at-a-time compiles
> >  unused inline function
> > 
> > hubicka at ucw dot cz wrote:
> > 
> > >------- Additional Comments From hubicka at ucw dot cz  2004-02-03 11:00 -------
> > >Subject: Re:  [3.4/3.5 Regression] -funit-at-a-time compiles unused inline function
> > >
> > >  
> > >
> > >>------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-02-03 09:25 -------
> > >>The code is indeed invalid.
> > >>
> > >>When a complete object of type X<int> is created, the compiler is allowed to
> > >>emit the vtable for X, and that permits instantiating the virtual functions.
> > >>
> > >>However, this is an optimization deficiency in -funit-at-a-time.
> > >>    
> > >>
> > >
> > >Yes, the problem is that all dependencies are resolved before
> > >optimization is done.  I am planning to address this by doing early pass
> > >of tree-ssa optimization before inlining and cgraph construction.  That
> > >way we should catch majority of cases.
> > >I also plan to deffer output of datastrctures to the very end of
> > >compilation and use information about what was really used by backend.
> > >
> > >Honza
> > >
> > What do you suggest, if anything, for GCC 3.4?
> > 
> > (This is potentially a regression with respect to the size of the 
> > generated code.  There is lots of code with trivial constructors that, 
> > after inlining, will be eliminated.)
> 
> I think we can keep it as it is now.  I did quite huge amount of
> measuring and the unit-at-a-time is a win for majority of C++ programs,
> so I think the other benefits outweight it.
> It is quite dificult to solve with current framework, unforutnately,
> since we discover such facts only during RTL expansion pass and because
> we mix analysis and optimization, we want to order things in a way so
> calees are compiled first and thus we can't take them back.  My CFG
> transparent expansion/inlining project is all about getting this
> chicken-egg problem broken up.
> 
> Note that if the constructor get inlined to all call sites, it's out of
> line copy will be elliminated.  We only lose in the case the
> constructor is not inlined for whatever reason and then the call site is
> removed later, for instance because the code turns out to be dead.  This
> don't seems to be terribly common in real code from what I've seen.
> 
> Another problem is that we don't have ability to elliminate static
> cosntructors when static variable turns out to be unnecesary.  Richard
> did some work on this, but didn't finished it, I plan to look into it
> after tree-SSA merge.

Actually looking deeper into this specific testcase,  I believe that if
the source program was correct, unit-at-a-time would emit empty file
too, since there is no entry point from where the call in question can
be reached, so it just builds the program representation in memory prior
optimizing it.
This is because of your request to change C++ frontend that way (my
initial patch didn't force instantiation of all TREE_USED templates).

I think this is correct thing - GCC should error out on this testcase.
Why it is considered a bug at first place?

Honza
> 
> Honza
> > 
> > 
> > 
> > -- 
> > 
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13768
> > 
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug, or are watching the assignee.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13768
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.


-- 


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