[Bug target/29487] Shared libstdc++ fails to link

["amylaar at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #35 from amylaar at gcc dot gnu dot org  2007-02-06 11:10 -------
 (In reply to comment #25)
> I think the analysis should be deeper than just "binds_local_p", though;
> I think it should be based on whether "attribute ((weak))" (or
> equivalent) explicitly appears, so that we don't pessimize bar if foo is
> in a template function, out-of-line inline, or other such function.  The
> test ought to be based on the demonstrable intent of the user to replace
> the function, not on whether or not the function happens to be weak.

Thinking a bit more about this, I agree.  If the function is declared
in the same translation unit, and no attribute or pragma prevents the
function from being inlined, it is already fair game for inlining, irrespective
of wether it binds locally or not.  Thus, if we decide for pragmatic reasons
(code size, snafus in analysis) not to inline such a function, we should still
be able to use analysis results about nothrow, const and pure characteristics
of the function.

When we get to the point where we can do cross-module optimizations (LTO or
otherwise), some other issues arise:
The situation is a bit different if the function is defined in a different
translation unit.  For shared libraries, putting functions into separate
translation unit is a common technique to show that the function should
not be inlined into a function in a different translation unit, or any
analysis results applied to a caller/callee in a different translation unit.
But it would make sense to have an option to enable such inlining / analysis,
and even to turn it on by default, since for any ordinary conformant program
the one-definition rule applies.


-- 


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