> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law <l...@redhat.com> wrote: > > On 9/26/18 7:38 AM, Jason Merrill wrote: > >> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguent...@suse.de> wrote: > >>> IIRC he explicitely wanted 'static' not 'hidden' linkage. Not sure > >>> what 'internal' would mean in this context. > >> > >> I mean internal linkage as in the C and C++ standards. > > > Since this is primarily for kernel hot patching, I think we're looking > > to restrict inlining to functions that have visibility limited to a > > compilation unit. > > Right, which is internal linkage. > > C11: "Within one translation unit, each declaration of an identifier > with internal linkage denotes the same object or function." > C++17: "When a name has internal linkage, the entity it denotes can be > referred to by names from other scopes in the same translation unit." > > Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as > richi suggested.
I am not quite sure if we can relate visibility flags we have at this stage to visibility in source languge in very coherent way. They change a lot with LTO and we may want to make this option incompatible with LTO, but even w/o we can turn function static that previously wasn't. For example comdat that was cloned by IPA-SRA. See can_be_local_p and comdat_can_be_unshared_p predicates. Similar problem happens to clones created by ipa-cp. I guess we want to disable localization and cloning in this case as well. I wonder what else. Honza
