| Message ID | f901b8d1-2001-41a7-f513-a5f0234cf0df@suse.cz |
|---|---|
| State | New |
| Headers | show |
| Series | Bump LTO bytecode version. | expand |
On Wed, Mar 18, 2020 at 9:54 AM Martin Liška <mliska@suse.cz> wrote: > > Hi. > > I would like to bump LTO bytecode version for the upcoming GCC 10.1 release. > > Ready for master? Um, is there any recent change warranting it? The version is already different from GCC 9s and I'd rather wait until we're closer to the actual release? Note the LTO major doesn't match the GCC major ... Richard. > Martin
On 3/18/20 9:56 AM, Richard Biener wrote: > On Wed, Mar 18, 2020 at 9:54 AM Martin Liška <mliska@suse.cz> wrote: >> >> Hi. >> >> I would like to bump LTO bytecode version for the upcoming GCC 10.1 release. >> >> Ready for master? > > Um, is there any recent change warranting it? The API extension reshuffles lto_section_type enum values. > The version is already different > from GCC 9s and I'd rather wait until we're closer to the actual release? Note > the LTO major doesn't match the GCC major ... But yes, the last change happened in: commit 86c23d9314c4081c13ebf629fd3393de4e316bf6 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu May 16 11:30:41 2019 +0200 * lto-streamer.h (LTO_major_version): Bump to 9. From-SVN: r271284 which is right after stage1 opened. Is it fine break LTO bytecode during the development of a new release? Martin > > Richard. > >> Martin
On Wed, Mar 18, 2020 at 10:00 AM Martin Liška <mliska@suse.cz> wrote: > > On 3/18/20 9:56 AM, Richard Biener wrote: > > On Wed, Mar 18, 2020 at 9:54 AM Martin Liška <mliska@suse.cz> wrote: > >> > >> Hi. > >> > >> I would like to bump LTO bytecode version for the upcoming GCC 10.1 release. > >> > >> Ready for master? > > > > Um, is there any recent change warranting it? > > The API extension reshuffles lto_section_type enum values. > > > The version is already different > > from GCC 9s and I'd rather wait until we're closer to the actual release? Note > > the LTO major doesn't match the GCC major ... > > But yes, the last change happened in: > > commit 86c23d9314c4081c13ebf629fd3393de4e316bf6 > Author: Jakub Jelinek <jakub@redhat.com> > Date: Thu May 16 11:30:41 2019 +0200 > > * lto-streamer.h (LTO_major_version): Bump to 9. > > From-SVN: r271284 > > which is right after stage1 opened. > Is it fine break LTO bytecode during the development of a new release? Yes, we don't really bump everytime we change something. Richard. > Martin > > > > > Richard. > > > >> Martin >
On 3/18/20 10:34 AM, Richard Biener wrote:
> Yes, we don't really bump everytime we change something.
Fine, then please forget about the patch.
Martin
From b48f4187e11da79d1b0a932b120eeee2f882defc Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Wed, 18 Mar 2020 09:40:24 +0100 Subject: [PATCH 3/3] Bump LTO bytecode version. gcc/ChangeLog: 2020-03-18 Martin Liska <mliska@suse.cz> * lto-streamer.h (LTO_major_version): Bump to 10. --- 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 76aa6fe34b8..9c1c7539462 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 10 #define LTO_minor_version 0 typedef unsigned char lto_decl_flags_t; -- 2.25.1