https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63986
--- Comment #5 from ppalka at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > Ok, now already existing forwprop code gets fed with > > <bb 2>: > _3 = a_2(D) == 0; > x_4 = (char) _3; > _7 = ~_3; > _8 = (int) _7; > MEM[(int *)d_5(D) + 8B] = _8; > if (x_4 != 0) > > where we now in the first forwprop pass identified the opportunity > to use ~_3 instead of x_4 == 0 thus x_4 is now no longer multi-use. > This makes us optimize if (x_4 != 0) to if (_3 != 0) which we > re-optimize in fold_gimple_cond now to '_3' and then of course > if (_3 != 0) (err, and we return "changed"....) which means we > now propagate _again_ via forward_propagate_into_gimple_cond > which now specifically allows aggressive forwarding of compares, > bypassing single-use restrictions. See > > 2014-11-16 Patrick Palka <ppa...@gcc.gnu.org> > > PR middle-end/63790 > * tree-ssa-forwprop.c (forward_propagate_into_comparison_1): > Always combine comparisons or conversions from booleans. > > thus me fixing my "mistake" does not help anymore. I worried that such an issue might pop up... If you think my patch should be reverted, note that there is a more benign version of the patch here https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00963.html (which still fixes the test case I was originally interested in fixing).
