https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #28 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Sergei Trofimovich from comment #25) > (In reply to Sergei Trofimovich from comment #22) > > (In reply to Martin Liška from comment #17) > > > For me tree optimized dump is correct, so likely a target issue. > > > > Yeah, I agree. I finally understood why memory loads disappear (duh!). > > > > > @Sergei: Is GCC 9 working properly? > > > Would it be possible to bisect that? > > > > gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated > > optimization passes change the code enough. > > > > I'll try to cook up even smaller example given that -fno-delayed-branch > > seems to be a culprit and then bisect gcc. > > Bisected down to: > > $ git bisect good > 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf is the first bad commit > commit 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf > Author: Martin Liska <mli...@suse.cz> > Date: Wed Dec 4 11:13:49 2019 +0100 > > Initialize a BB count in switch lowering. > > 2019-12-04 Martin Liska <mli...@suse.cz> > > * tree-switch-conversion.c > (switch_decision_tree::try_switch_expansion): > Initialize count of newly created BB. > > From-SVN: r278959 > > gcc/ChangeLog | 5 +++++ > gcc/tree-switch-conversion.c | 1 + > 2 files changed, 6 insertions(+) Thank you for the bisection. However, this one is not a culprit commit, it only made it visible. Let's wait for can Erik find out.
