https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123
--- Comment #15 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- Created attachment 37284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37284&action=edit Patch I'm testing to fix the bug The problem arises because we used to drop overwritten MEMs from loc lists of VALUEs, but not of other onepart variables, and it just so happens that, by doing so, block 6 has no D#5 in its output in the first pass, because the MEM holding its (previous) value was correctly dropped from value 88:88, but gains it in pass 2 because D#5 has the MEM location incoming directly in its loc list, rather than indirectly in a VALUE. This incorrect binding enables other blocks to believe they have a tentative binding for D#5 in some cycles, but others, still operating on the early conclusion, believe there isn't, and they oscillate. Since we check for escaping MEMs in clobbers, we won't lose anything relevant by dropping call-clobbered or overwritten MEMs in all onepart variables. The attached patch also includes some changes to the dataflow set compare function to make it more verbose when requested, which helped me figure out what was going on. I'll probably split it out into a separate patch when I submit the patch.
