https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at redhat dot com
--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The problem with FORTIFY_SOURCE wrappers is that they break invariant that
inline and offline versions of the functions are interchangeable and have same
semantics. I suppose this is the case of more GNU inline uses (and I hope it is
limited to those - what does C standard says about its semantics of extern
inline?) but we need to keep that separate from extern inlines autogenerated by
C++ frontend for keyed functions/externally instantiated functions which are
guaranteed to have same semantics as their offline variant. Handling those
conservatively is a bad idea because it would bring way too many additional
function bodies to LTO and confuse code size metrics.
I think the proper approach to handle GNU inline would be the following
1) extend cgraph code to support symbols that are both syntactic aliases and
function definitions
2) teach lto-symtab that extern inlines are never prevailing symbols, so alias
walks points to the external definition
3) avoid GNU extern inlines to be merged because they do not need to have same
semantics as the offline variant of the function. (we need to be sure that this
won't happen for C++ keyed functions)
4) teach inliner to inline extern inline instead of looking for alias target if
call goes directly to extern inline and ignore the extern inlines in most of
the other optimization passes (which would happen if alias walker walked to the
finallink). We can still consider cloning in ipa-cp of those if that helps to
clone calls within the extern inline function that targets non-inline
this should preserve current semantics even in case one would LTO fread
implementation. But for release branches I think we should avoid that and
simply target to get FORTIFY_SOURCE working when glibc is not LTO optimized.
For that I think fixing ipa-cp heuristics should work. We still may inline
fortify source wrapper into a call that was originally from unit withould
DFORTIFY_SOURCE. Is that considered a show stopper? If so, i can disable
inlining of GNU extern inlines that are not called directly but via attribute.
Martin (Jambor), can you please look at the ipa-cp bits?
If this conservative approach fails, i can work on 1), but that would require
changes on multiple places - at the moment we do not expect that symbol can
define two things (function body and alias)
