https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109724
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- I checked 11 and 12 and they are not affected. We run in circles through valueize_refs_1 in vn_reference_maybe_forwprop_address, repeatedly picking up _24 = &MEM <const struct SkDCubic> [(const struct SkDPoint &)iftmp.77_74].fPts[idx2_62].fX; where the available definition for the value if iftmp.77_74 is _24. We have <bb 70> [local count: 224314031]: _24 = &MEM <const struct SkDCubic> [(const struct SkDPoint &)iftmp.77_74].fPts[idx2_62].fX; _259 = minX; _260 = MEM <const struct SkDCubic> [(const double &)iftmp.77_74].fPts[idx2_62].fX; and the def of _74 is iftmp.77_74 = PHI <iftmp.77_178(64), iftmp.77_177(65)> _177 is iftmp.77_177 = &this_93(D)->fPart.fCurve; abd _62 is value-numbered to zero. But since on the 10 branch we have get_addr_base_and_unit_offset without valueization we likely do not notice the address doesn't actually change. Backporting r11-199-g2b42509f8b7bdf fixes this issue (well, it avoids it). I'm not 100% sure it doesn't just make the issue latent.
