------- Additional Comments From jh at suse dot cz 2005-09-03 10:51 -------
Subject: Re: -fvisibility-inlines-hidden broken differently
>
> ------- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-03
> 01:03 -------
> Frankly, I think -fvisibility-inlines-hidden is a bad idea. I don't feel that
> way about -fvisibility, but giving inline functions special linkage in this
> way
> is a very fragile concept, and awards something with minimal C++ semantics
> ("inline") substantial observable semantics.
>
> The documentation for -fv-i-h is not clear about this case. All it really
> says
> is that any inlines emitted will be hidden. The compiler's meeting that
> requirement, trivially, because it's not emitting any inlines.
Is that even correct that we don't emit any inline? (ie see bellow)
>
> I don't think that we should do anything different in *this* source file
> because
> -fv-i-h is present. The thing we actually want to know is how the file
> containing the vtable is going to be compiled, and we can't know that here.
> Therefore, it seems to me that the mistake in Michael's chain of events is:
>
> 4) the call is emitted such that it expects a local (hidden) definition
> of the function in the DSO (i.e. not over PLT but direct call)
>
> Nothing in the semantics of -fv-i-h says that all inline functions in the
> program will be in this DSO. If we were to try to believe that, other things
> (like "extern template") would probably break too. Instead, the linker should
> have the responsibility of binding the relocation within the DSO at DSO
> link-time, if there happens to be a satisfying symbol at link time.
>
> Jan, I don't think your patch is correct, as I don't think anything about the
> optimization of this program should change based on -fv-i-h.
Hmm, OK, there are two problems I see.
One problem is that this testcase breaks. We can declare it invalid or
one other possibility I run across is to teach locally_bound predicate
in varasm to not believe that this hidden inline function is going to be
linked locally. This is very similar to way -fvisibility works - ie
function is hidden only if defined in current unit and would result in
DSO to build and even link if the other DSO will export the inline
function (that won't happen with -fv-i-h on the other DSO, right?)
This is not quite trivial, becuase -fv-i-h is hanled in the frontend and
backend already don't see whether the particular inline was actually
declared hidden (where user should provide it in within same DSO) or
whether the hidden implied this way, but I guess we can simply be
conservative here and when flag is active, thread this way all comdats
with inline flag and hidden visibility.
But the more general problem however is that I think it is quite
incorrect to call comdat linkonce function directly without actually
outputting it into current compilation unit, at least from the
definition of comdat flag:
/* Used in a DECL to indicate that, even if it TREE_PUBLIC, it need
not be put out unless it is needed in this translation unit.
Entities like this are shared across translation units (like weak
entities), but are guaranteed to be generated by any translation
unit that needs them, and therefore need not be put out anywhere
where they are not needed. DECL_COMDAT is just a hint to the
back-end; it is up to front-ends which set this flag to ensure
that there will never be any harm, other than bloat, in putting out
something which is DECL_COMDAT. */
Making direct call the function probably makes function "needed in this
translation unit" even tought it wasn't originally. This can happen
with and without the patch in this special case (COMDAT functio being
originally referenced by vtable not going to be output here). Is there
something behind scenes making this safe? (like is the argument that
the function will be provided by unit defining vtable anyway safe and if
so, why is not frontend emitting it as extern inline in all other units
saving object file sizes?)
If not, we probably should prevent the folding...
Honza
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592
>
> ------- 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=22592
