This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Bump LTO_major_version
> On Mon, 29 Nov 2010, Jan Hubicka wrote:
> > >
> > > This bumps the LTO major version and makes us reject LTO objects built
> > > with 4.5 instead of crash in the option handling code.
> > Uh, thanks for looking into this!
> > >
> > > I tried to look at incorporating some checksum like we do for PCH, but
> > > the mechanism can't be easily re-used and I'm somewhat lost how to
> > > tackle the Makefile dependency issues given that LTO isn't always
> > > enabled (I thought of doing a lto1-checksum.c similar to the cc1
> > > and cc1plus ones and just re-use the same checksum in all frontends -
> > > which makes their link depend on lto1-checksum.c, conditionally).
> > Perhaps we can take the route of Andi's patch that checksums objects rather
> > than binaries (he did that to speedup bootstrap-lto). Then we can checksum
> > libbackend objects only.
> It just also occured to me that I would have disliked having the
> (for example lto1) checksum as part of the object - that way tracking
> down SPEC 2k6 link-time bugs by patching around in the source would
> have been very very annoying ...
> So I guess we really don't want _this_ strict testing ...
Well, we still break .o compatibility with each change in command line options,
so I never really was succesful to be able to use .o files from older build in
my work. Sure it is bad.
I see that this makes it even worse because I would be forced to rebuild mozilla
tree each time I make simple change in the backend. I am ready to comment the test
out for this reason however.
> Thus, let's not care for trunk builds and try to make sure we don't
> break compatibility too much on a branch (or remember to bump
> the LTO minor version).
We still have problem with objects form different hosts not being compatible.
One option, definitely not terribly cool either, would be to checksum the lto-streamer/lto-cgraph
and friends only.