> > >> I should have been clearer about Darwin: > > >> > > >> collect2 is required because it wraps the calling of lto-wrapper and ld. > > >> > > >> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not > > >> aware of anyone actually > > >> using case #2 from Jonathan’s post. > > >> > > >> So, AFAIK the tlink capability isn’t required for modern C++ on Darwin; > > >> but, maybe deprecation is a > > >> safer step. > > > > > > Thank you for the information. > > > > > > Yes, I would be fine to deprecate that for GCC 10.1 > > > > “thinking aloud” - would it work to deprecate (or even disallow immediately > > if no-one is using it) LTO + frepo? > > (so that non-LTO frepo continues as long as anyone needs it) > > Does that even work? ;) It would need an intermediate compile-step to > instantiate templates to > another LTO object.
It is iterating the linker executions so it definitly makes no sense. One problem is that in the collect2 at the time of deciding whether to open temporary file for the linker output (which is the problem Martin tries to solve) we do not know yet whether we will do -flto (because that will be decided by linker plugin later) or repo (because it works by looking for .repo files only after the link-step failed). I suppose we could block -frepo when -flto is on the command line that is most common case for LTO builds arriving to bit odd situation that at link-time -flto will effect nothing but colors of diagnostics (I would really like to have this solved for gcc 10 in some way) Honza > > Richard. > > > > > Iain > > > > > > > >
