https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #8)
> I still don't understand why propagating one SSA_NAME for another is causing
> headaches later though.
TBH, I don't either.
When I compile the .c test in this PR with the following options:
-O2 -fno-tree-scev-cprop -fdisable-tree-ccp1 -fdisable-tree-ccp2
-fdisable-tree-copyprop1 -fdisable-tree-evrp -fdisable-tree-vrp1
-fdisable-tree-ccp1 -fdisable-tree-ccp2 -fdisable-tree-ccp3
...I still get an ICE, but there is no change in the IL between trunk without
the offending patch, and with the patch that broke the test. This would
indicate that there is some on-the-side structure that is being altered by the
phi argument propagation.
I did notice that the IL *does* change in the middle of one of the copyprop (or
ccp?) passes, but it gets cleaned up to whatever was there before.
Later in SCEV, we ICE while trying to look at the SSA_NAME_DEF_STMT of an SSA
which no longer exists in the IL. This happens in
chrec_contains_symbols_defined_in_loop(). A wild guess is that the loop info
is getting mucked up somehow.
I can investigate more deeply if desired, but since this was a silly typo, I'm
gonna leave it alone for now.
Closing as fixed in mainline.
