https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #9 from Jeffrey A. Law <law at redhat dot com> --- So, just to record some thoughts. There's about a half-dozen patches, mostly from the August timeframe that will make this bug go latent. The general theme across them is they change the order in which we visit statements in sccvn/vrp, twiddle the set of SSA_NAMEs live ever so slightly prior to ccp & vrp or avoid setting ranges to names that we're going to full propagate away. The last has been the most fruitful in terms of starting to understand what's going on. Essentially by avoiding setting ranges on SSA_NAMES we're going to propagate away in evrp, we're changing the behavior of ccp! That (of course) doesn't seem right. I do know that we end up equating two SSA_NAMEs in the sccvn code. It *appears* that we don't undo the sharing of range info between them. EVRP comes along and stomps on the (now shared) range info (particularly the mask used by bitcpp). That in turn appears to be causing bitcpp to incorrectly simplify some integer arithmetic that presumably causes things to go awry later. I'm going to try and reduce the testcase tomorrow looking for the dump file differences in ccp2. While that won't produce a working executable, it ought to make the analysis phase of how/why we're sharing range info, why the info gets overwritten, etc a bit easier to follow (not to mention faster). Anyway, just recording thoughts from last night's late debugging session.
