Michał Górny <[email protected]> wrote: > > Dnia 2014-04-22, o godz. 08:45:31 > Martin Vaeth <[email protected]> napisa=B3(a): > >> On the other hand, if upstream tests and supports LTO, it should >> be communicated to the user somehow that this is the case. >> The same dilemma applies to some other CFLAGS which should not be >> used in general but only if the code is written for them. > > Why do you believe that LTO 'should not be used in general'?
In the last sentence, I did not have LTO in mind but things like -fmerge-all-constants -fnothrow-opt -fno-enforce-eh-specs or -fno-common. The latter is perhaps again a bit similar to LTO: > As far as I understand, the LTO concept is suited well for most > programs For programs yes, but if libraries are involved often not: Experience shows that most packages which provide or use (internally) libraries break with LTO if upstream does not care about. In particular, unless gold linker is expected (which unfortunately cannot be so easily changed locally for a package and which causes other problems if used system wide), it can make sense to compile only certain parts of the package with LTO (e.g. the main binary). That's why it can make sense to let the package care about the -flto CFLAG. > (+ the usual limitations like memory). not to forget compilation time which increases by the remarkable factor 2, at least (unless optimized for lto with e.g. -fno-fat-lto-objects).
