https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 18 Jan 2017, law at redhat dot com wrote: > 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. Range info shouldn't be "shared" - where does this bougs sharing happen? Richard.
