[Bug middle-end/49938] [4.7 regression] ICE in interpret_loop_phi, at tree-scalar-evolution.c:1645

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.08.02 09:46:57
                 CC|                            |spop at gcc dot gnu.org
          Component|c++                         |middle-end
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-02 09:46:57 UTC ---
Confirmed.

#2  0x0000000000ecb2b8 in interpret_loop_phi (loop=0x2aaaad43ca18, 
    loop_phi_node=0x2aaaad44f400)
    at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:1645
1645          gcc_assert (TREE_CODE (new_init) != POLYNOMIAL_CHREC);
(gdb) call debug_generic_expr (new_init)
{0, +, 2}_1
(gdb) call debug_generic_expr (res)
(unsigned int) {(size_type) {0, +, 2}_1, +, D.8756_24}_1

I'm not sure why the assert should be valid here.  {0, +, 2}_1 is
unsigned int, folding correctly sees that first widening unsigned int
to sizetype and then truncating back is useless.

What's the problem with dealing with a POLYNOMIAL_CHREC here?  Why
not simply return chrec_dont_know instead of asserting?