[Bug debug/68909] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68909

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think this testcase just shows that the PR67778 fix is insufficient.
We again have a complex cfg full of various loops, followed by a single bb
(bb10 in this case) that needs frame pointer.
Again, we see:
Attempting shrink-wrapping optimization.
Block 10 needs the prologue.
After wrapping required blocks, PRO is now 10
Avoiding non-duplicatable blocks, PRO is now 10
Bumping back to anticipatable blocks, PRO is now 6
where putting prologue at the entry of bb10 is fine, but putting it at the
entry of bb6 (shrink-wrapping actually creates bb11 with the prologue and
redirects edges from bb8 and bb5 to the new bb11 and bb11 then falls through to
bb6) is wrong.  While bb5 is only reachable from bbs before the prologue, so
that is fine, bb8 is reachable both from bb2 (i.e. from bbs before the
prologue), but also from bb9, which is dominated by bb6.  So, by incorrectly
putting the prologue at the start of bb6 (well, that bb self-loops, so it is
put on the other edges), we then can take path from ENTRY -> bb2 -> bb3 -> bb5
-> bb11[prologue] -> bb6 -> bb7 -> bb9 -> bb8 -> bb11[prologue] and enter the
prologue 2 times (or more times).