[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
tbsaunde at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Jan 9 01:58:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644
tbsaunde at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tbsaunde at gcc dot gnu.org
--- Comment #5 from tbsaunde at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> Verified reverting the tree-ssa-ccp.c hunk of r242920 makes the ICE go away
> (then instead of _18 = _7 + _17; there is _18 = x2_3 + _17;
> (no idea why _7 hasn't actually been replaced with 0 but just with x2_3,
> though there is UB involved in the loop if x4[0] isn't 0 at the beginning)).
I think that is because match.pd doesn't have a pattern for x / 0, and nothing
else that would clean it up is run with -Og.
What happens is basically this, we first evaluate blocks in the order 2 4 5 3
4. So we first add _7 = 0, _15 = {0, 0, 0, 0}, _16 = 0, and _18 = _17 to the
latice. Then when we evaluate block 3 we set x2_4 to varying, and leave x3_2
as 0. Then we meet x2_4 and 0 and set _7 = x2_4 in the latice. Then when we
try and evaluate _15 = {_7, _7, _7, _7} we fail to meet the new value of {x2_4,
x2_4, x2_4, x2_4} and the old {0, 0, 0, 0} because set_latice_value doesn't
know how to handle meeting vector constants like that. Then evaluating _16 =
BIT_FIELD_REF<_15, 128, 0> we enter _16 = _7 into the latice because
gimple_simplify doesn't try to valueize _7. Then substitute_and_fold visits
the statement using _16 and replaces it with _7 and doesn't check if _7 should
also be replaced there.
It seems like there is basically 3 options for fixing this.
- make gimple_simplify try to simplify the ssa name it gets out of the vector
cst, but I guess the design is that should already be simplified.
- in get_constant_value if const_val[i] is a ssa name look up the value of that
ssa name. That seems simplest and least prone to other issues, but maybe there
is a need for all entries in const_val[] to be completely simplified?
- make set_latice_value and ccp_latice_meet correctly merge the 2 vector csts.
I'm not completely sure if that's even possible in all cases with vectors that
have different elements.
More information about the Gcc-bugs
mailing list