[Bug c++/22592] -fvisibility-inlines-hidden broken differently

["matz at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From matz at suse dot de  2005-09-05 07:35 -------
I want to add a comment to Mark's comment #5: I also thought about multiple 
solutions to this problem, and in the end came to the conclusion that 
disabling devirtualization in the current state of the compiler is the best. 
My reasons for different options: 
  * don't support -fv-i-h anymore: that would trivially solve the problem, 
    but at the expense of deactivating a sometimes quite effective 
    optimization (especially with template heavy code, in the light of 
    non-class-member inlines), so I would like to retain the option itself 
    and support it as best as possible, even when this means to stretch 
    the C++ standard a bit in some corner, as this is just an option for 
    those who know what they are doing 
 
  * emit all referenced inlines in the compilation unit of reference, 
    as linkonce.  This also would solve the problem of the direct call, 
    as now the implicit condition is met, that the function is indeed 
    forced local.  But with the current infrastructure in 4.0 (and even 4.1), 
    this means that we would have to emit all _potentially_ referenced 
    inlines, because devirtualization can make random functions called 
    directly which weren't before.  This would increase the memory 
    footprint of GCC again and as such is suboptimal. 
 
  * only localize (and hide) inline functions which are not class members. 
    This would solve this problem, because only class member inlines are 
    in danger of suddenly being called directly, when they formerly were 
    only called over the vtable.  I haven't thought much about this solution, 
    but I think it's very feasible also.  At least it should retain 
    most of the meaning of the -fv-i-h option, in that it reduces the 
    exporting of many out-of-class inline functions, particularly templates. 
 
  * disable devirtualization.  Solves the problem, and has the least 
    effects regarding code quality.  AFAIK currently devirtualization 
    is not used for very many interesting things.  Inlining happens 
    before, so we don't get more inlining opportunities.  Attributes 
    like constness are available before, so optimizations relying on them 
    are also possible on the indirect vtable-call.  And what finally 
    convinced me was the fact that calls over the vtable are actually 
    faster than calls over the PLT.  The call over PLT includes the call 
    to the PLT stub, the fetch of the address and the jump to the final 
    address (at first call also the symbol resolution).  The vtable call 
    includes the fetch of the address and the call to it. 
 
So all in all I think the best trade off is the last option.  At the expense 
of a missed optimization (which doesn't happen very often, as we can see 
how often this bug happens, and if it happens then it's IMHO not very 
effective currently) he get's a program working with this option, and with 
the effects this option should have (less exported "fake" symbols). 

-- 


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