https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
--- Comment #20 from Chris Clayton <chris2553 at googlemail dot com> --- On 08/07/2022 15:02, Chris Clayton wrote: > Hi > > On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 >> >> Andrew Pinski <pinskia at gcc dot gnu.org> changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Status|UNCONFIRMED |WAITING >> Ever confirmed|0 |1 >> Last reconfirmed| |2022-07-03 >> > > I some additional diagnostics (the result of a bisect) to the bugzilla report > earlier this week. The first bad commit > was 8c99e307b20. > > I've been busy since but have just checked out the first bad commit's parent > commit (54a5f478487) and built with > gcc-12-20220702. That build completed successfully. As an update, I've just tried to build the gcc-13-20220717 snapshot using a compiler built with gcc-12-20220716 snapshot. The outcome is the same set of ICEs. I've also realised this morning that I forgot to add the author of the first bad coomit from the bisect that I reported the results of. So, al...@redhat.com added as recipient of this email. Aldy - the first bad commit from the bisect was 8c99e307b20c502e55c425897fb3884ba8f05882 (Convert DOM to use Ranger rather than EVRP). It seems to be involved in some way in a batch of ICEs I see when trying to build recent gcc-13 snapshots (20220626 and later) with recent gcc-12 snapshots. I aslo get the ICEs trying to build gcc-13 with a gcc-11 or gcc-10 compiler. The diagnostics I've collected are attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172 > >
