This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Can LTO minor version be updated in backward compatible way ?


Hi,

SuSE (Martin) annonunced today that fromw now on SuSE Tumbleweed will
ship with LTO-built packages by default [1].

That's a good news, however I have a question wrt how you expect to
support LTO in the future. I have been enabling it in my company for
just few selected components and I run into trouble several times these
last years. In the LTO section you define both a major version and a
minor version, however changing any of them will result in LTO build to
fail if all binaries involved in the link don't strictly have the exact
same version. Recently in gcc 9 we went from version 8.0 to 8.1. In the
past in gcc 8 I recall I also hit a problem when it went from 7.0 to
7.1. In my case, it meant recompiling a set of let's say 100 open source
libraries, and around 30 different proprietary libraries (we use static
linking, that's why all libs have to be rebuilt each time we upgrade gcc
to the next minor version). This is still bearable at my level, I don't
have too many dependencies.

However at scale, I think this can become a problem. What will happen
when in gcc 9.3 we change the version to 8.2 ? Will Tumbleweed recompile
100% of the static libraris it ships ? What about all users of
Tumbleweed having their own private libs with LTO as well ? In my company,
I don't advocate LTO at scale (yet) because of this problem in particular:
re-building everything when we release a toolchain with an updated gcc
would be too complex.

I am totally fine with having the major version mismatch as a
showstopper for the link. People will usually not combine a gcc 8 built
binary with a gcc 9 one. However if we have made a distinction with
major vs minor, is it possible to adopt a backward compatible policy in
the minor version ? Let's say I have a shiny new gcc 9, it can combine
both LTO binaries of version 8.0 and 8.1. Maybe it can emit a warning
saying it will work in degraded mode, but at least allow the build to go
on.

If having format backward compatible constraints is too hard inside a
given major gcc release, may we can consider another alternative to
failure. If fat objects were used, and if really the two minor
versions are really incompatible, maybe we can fallback on the non-LTO
part for the old library and still the link will be successful (but not
as optimized as we would like too, most likely warnings will notify
about that).

I have no idea of the LTO format and if indeed it can easily be updated
in a backward compatible way. But I would say it would be nice if it
could, and would allow adoption for projects spread on many teams
depending on each others and unable to re-build everything at each
toolchain update.

Cheers,
Romain

[1] https://lists.opensuse.org/opensuse-factory/2019-07/msg00240.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]