On Tue, Apr 20, 2021 at 11:57 AM Martin Liška <mli...@suse.cz> wrote: > > It seems we bumped LTO_major_version last time 2 years ago. > > Right now, the following is seen when one links a GCC 10.2.x LTO object file: > $ gcc a.o > > lto1: fatal error: bytecode stream in file ‘a.o’ generated with LTO version > 9.2 instead of the expected 9.0 > > > I suggest bumping LTO_major_version for releases/gcc-11 branch. > Can we please align it with a GCC release (version 11)? For the future, if > e.g. GCC 12 consumes LTO > bytecode from GCC 11, we can leave LTO_major_version. Once e.g. GCC 13 needs > bumping, > I would then change it to 13. > > What do you think about the suggested scheme? > Ready for gcc-11 branch?
OK. Can you somehow arrange for trunk to pick up LTO_major from GCC major automagically then? Thanks, Richard. > Martin > > gcc/ChangeLog: > > * lto-streamer.h (LTO_major_version): Bump to 11. > --- > gcc/lto-streamer.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h > index 5c7cd84d46f..7a7be80dab8 100644 > --- a/gcc/lto-streamer.h > +++ b/gcc/lto-streamer.h > @@ -120,7 +120,7 @@ along with GCC; see the file COPYING3. If not see > String are represented in the table as pairs, a length in ULEB128 > form followed by the data for the string. */ > > -#define LTO_major_version 9 > +#define LTO_major_version 11 > #define LTO_minor_version 0 > > typedef unsigned char lto_decl_flags_t; > -- > 2.31.1 >
