http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-08-27 17:35:27 UTC --- Carry, is there any chance to move ahead on this problem? I see you posted the PREVAILING_DEF_IRONLY_EXP but it was never committed. Concerning Rafael's comment: Why is PREVAILING_DEF_IRONLY_EXP needed? I think it can be solved with just PREVAILING_DEF if we say that the compiler can drop references to them if it knows they are provided in any DSO. The only case I can see where this would almost be a problem is something like This is not possible with current formulation of plugin API. It explicitely says "Any symbol marked PREVAILING_DEF must be defined in one object file added to the link after WPA is done, or an undefined symbol error will result" We could also go that route I guess, but 1) We will have to bump API version or something to indicate whether compiler is allowed to drop the symbols or not. With current binutils implementation bad things happens when compiler decided to drop the symbol it is not supposed to (my original implementation did so and it resulted in problems, especially in large dynamic linker tables) 2) the LTO produced COMDAT function will likely be better, so we will lose bit of code quality 3) There are cases where function is output COMDAT but it is keyed (i.e. with the repo files). In this case we will not be able to drop the symbol when it becomes unnecessary at LTO time because we will not know whether the symbol is used by non-LTO code or not. All those reasons are rather side cases and thus weak, but because we are effectively changing API anyway and because PREVAILING_DEF_IRONLY_EXP makes compiler a bit more informed in well defined way, I would go for it. Honza
