[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Wed Mar 29 09:28:46 2017
New Revision: 246561

URL: https://gcc.gnu.org/viewcvs?rev=246561=gcc=rev
Log:
2017-03-29  Richard Biener  

Backport from mainline
2017-03-28  Richard Biener  

PR tree-optimization/78644
* tree-ssa-ccp.c (evaluate_stmt): When we may not use the value
of a simplification result we may not use it at all.

* gcc.dg/pr78644-1.c: New testcase.
* gcc.dg/pr78644-2.c: Likewise.

2017-03-27  Richard Biener  

PR tree-optimization/80181
* tree-ssa-ccp.c (likely_value): UNDEFINED ^ X is UNDEFINED.

* gcc.dg/torture/pr80181.c: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78644-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78644-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr80181.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-ccp.c

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 28 13:57:43 2017
New Revision: 246534

URL: https://gcc.gnu.org/viewcvs?rev=246534=gcc=rev
Log:
2017-03-28  Richard Biener  

PR tree-optimization/78644
* tree-ssa-ccp.c (evaluate_stmt): When we may not use the value
of a simplification result we may not use it at all.

* gcc.dg/pr78644-1.c: New testcase.
* gcc.dg/pr78644-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr78644-1.c
trunk/gcc/testsuite/gcc.dg/pr78644-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #8 from Richard Biener  ---
Mine.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Richard, could you please have a look at this?

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[zsojka at seznam dot cz]

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

--- Comment #6 from Zdenek Sojka  ---
Created attachment 40981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40981=edit
another testcase

$ x86_64-pc-linux-gnu-gcc -Og -finline-functions-called-once testcase.c
-Wno-psabi
==20182== Invalid read of size 2
==20182==at 0x8D0572: is_gimple_reg_type (gimple-expr.h:75)
==20182==by 0x8D0572: is_gimple_val(tree_node*) (gimple-expr.c:782)
==20182==by 0xC11E70: verify_gimple_assign_unary (tree-cfg.c:3634)
==20182==by 0xC11E70: verify_gimple_assign (tree-cfg.c:4475)
==20182==by 0xC11E70: verify_gimple_stmt(gimple*) (tree-cfg.c:4732)
==20182==by 0xC25B29: verify_gimple_in_cfg(function*, bool)
(tree-cfg.c:5193)
==20182==by 0xABE056: execute_function_todo(function*, void*)
(passes.c:1966)
==20182==by 0xABF10B: execute_todo(unsigned int) (passes.c:2016)
==20182==by 0xAC15AD: execute_one_pass(opt_pass*) (passes.c:2505)
==20182==by 0xAC1CB0: execute_pass_list_1(opt_pass*) (passes.c:2554)
==20182==by 0xAC1CC2: execute_pass_list_1(opt_pass*) (passes.c:2555)
==20182==by 0xAC1D04: execute_pass_list(function*, opt_pass*)
(passes.c:2565)
==20182==by 0x752F12: cgraph_node::expand() (cgraphunit.c:2038)
==20182==by 0x754639: expand_all_functions (cgraphunit.c:2174)
==20182==by 0x754639: symbol_table::compile() [clone .part.51]
(cgraphunit.c:2531)
==20182==by 0x756D16: compile (cgraphunit.c:2624)
==20182==by 0x756D16: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2621)
==20182==by 0xBDD442: compile_file() (toplev.c:492)
==20182==by 0x5A457F: do_compile (toplev.c:2000)
==20182==by 0x5A457F: toplev::main(int, char**) (toplev.c:2134)
==20182==by 0x5A686A: main (main.c:39)
==20182==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==20182== 
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: Segmentation fault
 foo (U u, V v)
 ^~~

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[tbsaunde at gcc dot gnu.org]

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.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
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)).

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
So, before ccp4 we have:
  _7 = x3_1 + x2_3;
  _8 = {_7, _7, _7, _7};
  x4.1_9 = x4;
  _15 = {_7, _7, _7, _7};
  _16 = BIT_FIELD_REF <_15, 128, 0>;
  _17 = BIT_FIELD_REF ;
  _18 = _16 + _17;
  _19 = {_7, _7, _7, _7};
  _20 = BIT_FIELD_REF <_19, 128, 128>;
  _21 = BIT_FIELD_REF ;
  _22 = _20 + _21;
  _23 = {_7, _7, _7, _7};
  _24 = BIT_FIELD_REF <_23, 128, 256>;
  _25 = BIT_FIELD_REF ;
  _26 = _24 + _25;
  _27 = {_7, _7, _7, _7};
  _28 = BIT_FIELD_REF <_27, 128, 384>;
  _29 = BIT_FIELD_REF ;
  _30 = _28 + _29;
  _10 = {_18, _22, _26, _30};
   = _10;

ccp4 sees those uses:
_7 : -->20 uses.
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
...
Visiting statement:
_7 = x3_1 + x2_3;
which is likely CONSTANT
Match-and-simplified x3_1 + x2_3 to 0
Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.

and replaces all those ctors with {x2_3, x2_3, x2_3, x2_3}.
But folding also happens while this is ongoing:
Folding statement: _17 = BIT_FIELD_REF ;
Not folded
Folding statement: _18 = _16 + _17;
Folded into: _18 = _7 + _17;
and thus a new _7 reference appears, and we don't fold that into _18 = x2_3 +
_17, but remove the _7 setter, because we assume all uses are replaced:

Removing dead stmt _7 = x3_1 + x2_3;

Richi, I think this is your area of expertise.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'm seeing it starting with r242923, but that doesn't make any sense, the ICE
is in ccp4 and the dump before ccp4 looks identical between compiler that ICEs
and doesn't ICE.  So r242920 looks much more likely culprit from a close range
to that.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-02
  Known to work||5.4.1, 6.2.1
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.