https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122456
--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 62756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62756&action=edit patch 1 - still fails I adjusted the w_fold routine to - dump the ranges being calculated - dump the original range produced - dump the new range produced. I then collected all these values (~20,000) during a bootstrap up to the point were it fails I then provided all those to an AI and had it check if any of the new ranges were incorrect based on the input. In all cases, the new range was at least as precise, and never wrong. This lends credibility to the theory that the patch which caused this has likely uncovered a latent issue somewhere. Along the way, I also discovered that if I added enough debug info, bootstrap suddenly starts working. Attached is a patch which if added to trunk the bootstrap still fails. It moves the new code in wi_fold from the original patch to a derived version of operator_bitwise_and, and then invokes the original version if the new code isn't executed. The functionality remains the same, The derived version of AND also spits out some debug info. This patch continues to fail in the same way. There is also a second patch coming next which makes a minor tweak to the debug output in the derived class... and voila.. that makes the trap go away!!! Again, there is no real functional change. I will continue poking at it, but perhaps someone with more LTO skills can now look at what decision(s) this second patch changes and why between these two cases, it starts passing.. . that should hopefully lead us to where the problem is.
