This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 29 Feb 2016 09:41:31 +0000
- Subject: [Bug tree-optimization/69989] [6 Regression] ICE on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (in verify_loop_structure, at cfgloop.c:1639)
- Auto-submitted: auto-generated
- References: <bug-69989-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #3)
> WRT fallout and reverting on the gcc-5 branch. Based on what I'm seeing,
> that may make sense.
>
> The problem in this particular case is we've marked loops for fixup, then
> loop distribution is explicitly calling checking_verify_loop_structure.
>
> checking_verify_loop_structure will assert that loops do not need fixup, and
> of course, that assertion fails. There's at least a half-dozen of these
> explicit calls that can fail in a similar manner.
>
> I'm going to poke a bit, but my inclination is to pull the patch from the
> trunk and the branch.
Well, the remove_edge hook is very low-level so all the intelligent adjustments
we do in higher level cfg hooks may now get spurious fixups. For example
what loop distribution does should never get you more loops and the
checking_verify_loop_structure is supposed to check for that ...
[I've always chickened to add auto handling to the very low level CFG hooks...
eventually we might want to guard that in a way to only trigger on non-loop
passes or make high level CFG ops call _raw low-level workers avoiding those
updates]
I will have a look myself as well.