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

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---

We have two different SSA_NAMEs where their SSA_NAME_INFO is the same pointer. 
Thus modification range info by way of set_range_info changes the underlying
range on both SSA_NAMEs.  From a debugging session:

(gdb) p cfun->gimple_df->ssa_names.m_vecdata[1045].ssa_name.info.range_info
$33 = (range_info_def *) 0x7fffefa4a420
(gdb) p cfun->gimple_df->ssa_names.m_vecdata[938].ssa_name.info.range_info
$34 = (range_info_def *) 0x7fffefa4a420


So to follow how we get to that state.

First ccp_finalize calls set_nonzero_bits on SSA_NAME 938.  That allocates a
hunk of memory and initializes it with the right information.

Then ccp_finalize calls set_nonzero_bits on SSA_NAME 1045.  That allocates
another hunk of memory and initializes it appropriately.

The actual recorded ranges are different -- they differ in nonzero_bits.

So far, so good.  No problems.

Then FRE comes along and decides the two SSA_NAMEs are equal and executes this
code:

                 /* Use that from the dominator.  */
                  SSA_NAME_RANGE_INFO (to) = SSA_NAME_RANGE_INFO (from);
                  SSA_NAME_ANTI_RANGE_P (to) = SSA_NAME_ANTI_RANGE_P (from);



TO is SSA_NAME 1045, FROM is SSA_NAME 938.

At that point we have two distinct SSA_NAMEs with a shared SSA_NAME_RANGE_INFO
pointer.

EVRP then comes along and calls set_range_info on SSA_NAME 1045, which has the
side effect of changing the range info on SSA_NAME 938.  This changes the
nonzero bits associated with SSA_NAME 938 (which ultimately results in
incorrect code starting in a later CCP pass).

Shortly thereafter we release SSA_NAME 1045 because its LHS is going to be
fully propagated away.

And it makes perfect sense why last week'd change to not set range info on
statements marked for removal can cause this bug to go latent.  We avoid the
call to set_range_info on SSA_NAME 1045 and thus don't clobber the nonzero bits
for SSA_NAME 938.

FWIW, knowing that I can diff the .ccp2 dumps to look for evidence of this
issue gave me some hope I could reduce the testcase further without worrying
about still being able to execute the test.  Alas that didn't make any
significant difference -- a few things were removed, but not enough to
significantly simplify the test.

BTW, I don't expect to be online much over the next few days...  Good luck...