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?
