[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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.