https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
--- Comment #10 from Andrew Macleod <amacleod at redhat dot com> ---
It also works if I use
--disable-tree-cunroll
which makes me suspicious of cunroll.
It also works if I use
--fdisable-tree-evrp --fdisable-tree-vrp1
So I thought perhaps VRP is doing something to mess up cunroll.. however when I
look at the difference coming out of the pass before cunroll with the 2 sets of
options, the only code differences are negligible. And yet cunroll makes some
very very different decisions.
In theory that leaves global values which are exported by EVRP/VRP. Given that
turning off VRP1 by itself still causes the failure, that would imply either a
global exported by EVRP, and/or the utilization of SCEV by a VRP pass impacting
a global perhaps.
I then tried it with simply:
--param=vrp-block-limit=1
which invokes fast VRP, and does not then utilize SCEV/loop analysis.
This also passes on its own, while setting a number of the same globals.
(albeit will some different values due to the lack of loop info)
I don't see a VRP pass doing anything obviously wrong. Someone who understands
the cunroll pass can maybe discover what its making such different decisions
(which apparently cause the fault) when disabling evrp and vrp1 (or using fast
vrp)
