| Message ID | 52E61B35.5040605@sfr.fr |
|---|---|
| State | New |
| Headers | show |
>> Did you bootstrap & test the 4.7 backport? >> > Yes, works like a charm here. I also see the build problem (configuring with "--enable-languages=c,fortran --disable-bootstrap"). >> Looks like you committed C++ code there, in module.c: >> ... >> 3867 static void >> 3868 skip_list (int nest_level = 0) >> 3869 { >> ... >> >> This breaks build. In 4.7 gcc is still C, at least for >> cross-builds (cris-elf but unimportant): >> > Alright; can you try the attached patch? Does appear to fix the build problem. Did not check the testsuite ... Cheers, Janus
On Mon, 27 Jan 2014, Mikael Morin wrote: > Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit : > > On Sun, 26 Jan 2014, Mikael Morin wrote: > >> Le 18/01/2014 21:17, Mikael Morin a écrit : > >>> Well, I guess that due to the touchy nature of the bug, there are cases > >>> that work by luck on old versions and fail (by unluck) on newer ones. > >>> Thus, I will backport in a few days to 4.8 and 4.7. > >>> > >> I added the following hardening to the patch on the 4.8 backport > >> (http://gcc.gnu.org/r207117 and attached) and forward-ported it to trunk > >> (http://gcc.gnu.org/r207118) as well. > >> 4.7 will come in an hour or so. > > > > Did you bootstrap & test the 4.7 backport? > > > Yes, works like a charm here. Huh, so we have C for cross-builds and C++ for bootstraps. I wish we could retire that difference *also* on the 4.7 branch (using either C *or* C++ for *both* would be fine with me FWIW). I believe we're now eperiencing more problems than benefits with that difference, now that the migration is over. > > Looks like you committed C++ code there, in module.c: > Alright; can you try the attached patch? Sorry, not at the moment, but I see Janus took care of that (thanks) and it looks pretty obvious to me. It'll be noticed when it's committed... brgds, H-P
Hans-Peter Nilsson <hp@bitrange.com> wrote: >On Mon, 27 Jan 2014, Mikael Morin wrote: >> Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit : >> > On Sun, 26 Jan 2014, Mikael Morin wrote: >> >> Le 18/01/2014 21:17, Mikael Morin a écrit : >> >>> Well, I guess that due to the touchy nature of the bug, there are >cases >> >>> that work by luck on old versions and fail (by unluck) on newer >ones. >> >>> Thus, I will backport in a few days to 4.8 and 4.7. >> >>> >> >> I added the following hardening to the patch on the 4.8 backport >> >> (http://gcc.gnu.org/r207117 and attached) and forward-ported it to >trunk >> >> (http://gcc.gnu.org/r207118) as well. >> >> 4.7 will come in an hour or so. >> > >> > Did you bootstrap & test the 4.7 backport? >> > >> Yes, works like a charm here. > >Huh, so we have C for cross-builds and C++ for bootstraps. No, we use a C host compiler in both cases. Only stages 2 and 3 build with a C++ compiler. Richard. I >wish we could retire that difference *also* on the 4.7 branch >(using either C *or* C++ for *both* would be fine with me FWIW). >I believe we're now eperiencing more problems than benefits with >that difference, now that the migration is over. > >> > Looks like you committed C++ code there, in module.c: >> Alright; can you try the attached patch? > >Sorry, not at the moment, but I see Janus took care of that >(thanks) and it looks pretty obvious to me. It'll be noticed >when it's committed... > >brgds, H-P
On Mon, Jan 27, 2014 at 06:17:38PM +0100, Richard Biener wrote: > >Huh, so we have C for cross-builds and C++ for bootstraps. > > No, we use a C host compiler in both cases. Only stages 2 and 3 build with a C++ compiler. And even for stage{2,3} C can be optionally used by asking for it using a configure option. So, please no C++ on the 4.7 branch. Jakub
On Mon, 27 Jan 2014, Richard Biener wrote: > >Huh, so we have C for cross-builds and C++ for bootstraps. > > No, we use a C host compiler in both cases. Only stages 2 and 3 build with a C++ compiler. Tomatos potatoes! As fortran isn't built until then, it'll be built as C for cross-builds and C++ for native bootstraps. Can we make stage 2 and 3 built with C on the 4.7 branch? > > Richard. > I > >wish we could retire that difference *also* on the 4.7 branch > >(using either C *or* C++ for *both* would be fine with me FWIW). > >I believe we're now eperiencing more problems than benefits with > >that difference, now that the migration is over. > > > >> > Looks like you committed C++ code there, in module.c: > >> Alright; can you try the attached patch? > > > >Sorry, not at the moment, but I see Janus took care of that > >(thanks) and it looks pretty obvious to me. It'll be noticed > >when it's committed... > > > >brgds, H-P > >
On Tue, Jan 28, 2014 at 3:25 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote: > On Mon, 27 Jan 2014, Richard Biener wrote: >> >Huh, so we have C for cross-builds and C++ for bootstraps. >> >> No, we use a C host compiler in both cases. Only stages 2 and 3 build with a C++ compiler. > > Tomatos potatoes! As fortran isn't built until then, it'll be > built as C for cross-builds and C++ for native bootstraps. Can > we make stage 2 and 3 built with C on the 4.7 branch? You can, with a configure option. No, at this point we don't want to change the defaults. Richard. > >> >> Richard. >> I >> >wish we could retire that difference *also* on the 4.7 branch >> >(using either C *or* C++ for *both* would be fine with me FWIW). >> >I believe we're now eperiencing more problems than benefits with >> >that difference, now that the migration is over. >> > >> >> > Looks like you committed C++ code there, in module.c: >> >> Alright; can you try the attached patch? >> > >> >Sorry, not at the moment, but I see Janus took care of that >> >(thanks) and it looks pretty obvious to me. It'll be noticed >> >when it's committed... >> > >> >brgds, H-P >> >>
Index: module.c =================================================================== --- module.c (révision 207119) +++ module.c (copie de travail) @@ -3865,7 +3865,7 @@ find_symbol (gfc_symtree *st, const char *name, skipped here. The default value is 0 (balanced parens). */ static void -skip_list (int nest_level = 0) +skip_list (int nest_level) { int level; @@ -4228,7 +4228,7 @@ load_derived_extensions (void) if (!info || !derived) { while (peek_atom () != ATOM_RPAREN) - skip_list (); + skip_list (0); continue; } @@ -4465,18 +4465,18 @@ read_module (void) gfc_symbol *sym; get_module_locus (&operator_interfaces); /* Skip these for now. */ - skip_list (); + skip_list (0); get_module_locus (&user_operators); - skip_list (); - skip_list (); + skip_list (0); + skip_list (0); /* Skip commons, equivalences and derived type extensions for now. */ - skip_list (); - skip_list (); + skip_list (0); + skip_list (0); get_module_locus (&extensions); - skip_list (); + skip_list (0); mio_lparen (); @@ -4514,7 +4514,7 @@ read_module (void) if (sym == NULL || (sym->attr.flavor == FL_VARIABLE && info->u.rsym.ns !=1)) { - skip_list (); + skip_list (0); continue; } @@ -4531,13 +4531,13 @@ read_module (void) /* First seek to the symbol's component list. */ mio_lparen (); /* symbol opening. */ - skip_list (); /* skip symbol attribute. */ - skip_list (); /* typespec. */ + skip_list (0); /* skip symbol attribute. */ + skip_list (0); /* typespec. */ require_atom (ATOM_INTEGER); /* namespace ref. */ require_atom (ATOM_INTEGER); /* common ref. */ - skip_list (); /* formal args. */ + skip_list (0); /* formal args. */ /* no value. */ - skip_list (); /* array_spec. */ + skip_list (0); /* array_spec. */ require_atom (ATOM_INTEGER); /* result. */ /* not a cray pointer. */ @@ -4562,7 +4562,7 @@ read_module (void) skip_list (1); /* symbol end. */ } else - skip_list (); + skip_list (0); /* Some symbols do not have a namespace (eg. formal arguments), so the automatic "unique symtree" mechanism must be suppressed @@ -4725,7 +4725,7 @@ read_module (void) if (u == NULL) { - skip_list (); + skip_list (0); continue; }