https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
--- Comment #16 from Jan Hubicka <hubicka at ucw dot cz> --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 > > Richard Biener <rguenth at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |hubicka at gcc dot gnu.org > > --- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> --- > (In reply to Дилян Палаузов from comment #13) > > At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345#c4 is written that > > “Right now the plugin from any gcc can be used with any gcc.” This is not > > the same as the last comment. Please clarify again, if any gcc plugin can > > be used with any gcc. > > Well, liblto_plugin.so is only half of the story. Yes, using any version > will probably "work" but you might get better experience with using a newer > version (though that newer version might present older GCC with resolution > files they do not understand). I think we only extended resolution file for new resolution types passed by newer linkers, so it should be backward compatible to original implementation. Notable changes was made to pass -flinker-output. Both however matters only for the cases where linker is invoked from gcc command, not for ar/ranlib/nm. We may want to update symbol table eventually but I do not think it would be big deal to keep plugin understand old format becuse it is simple. > > > If several plugins can be installed simultaneously and the first one that > > claims the .o file wins, why aren’t plugins for both GCC7 and GCC8 installed > > at the same time? Just for gcc8 files, the gcc7 plugin will not claim the > > responsibility. > > It doesn't work that way since any liblto_plugin.so version will accept > any GCC LTO files. It is the lto-wrapper binary that is found to the > one matching the GCC driver version used to invocate the link that > ultimately determines your luck - here strict version matching is required. > Thus LTO linking objects from mixed GCC version is doomed to fail > fatally. > > Note plugin auto-loading will only work reliably for ar/nm/ranlib because > of this and indeed for those the version of the plugin doesn't really matter. Plugin interface should be good enough to allow LTO optimizing one binary with multiple compilers (multiple versions of GCC or GCC+LLVM combination) where obviously no cross-module optimization between compilers will happen but still each compiler will get acurate resolution data that will let it to optimize well within the portion of binary it understands. We are missing way to specify multiple plugins to linker and some other supporting bits I believe. Honza
