------- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-18 12:16 -------
confirmed.
#0 0x0000000000bca7e9 in bitmap_insert_into_set_1 (set=0x0, expr=0x1621e58,
allow_constants=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:640
#1 0x0000000000bca82d in bitmap_insert_into_set (set=0x0, expr=0x1621e58)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:650
#2 0x0000000000bcb036 in bitmap_value_replace_in_set (set=0x0, expr=0x1621e58)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:846
#3 0x0000000000bd1162 in create_expression_by_pieces (block=0x7ffff7597b40,
expr=0x1621d18, stmts=0x7fffffffd7d8, domstmt=0x7ffff7eb7f50,
type=0x7ffff758f540)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2820
#4 0x0000000000bd0c5f in find_or_generate_expression (block=0x7ffff7597b40,
expr=0x1621dd8, stmts=0x7fffffffd7d8, domstmt=0x7ffff7eb7f50)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2682
#5 0x0000000000bd0f78 in create_expression_by_pieces (block=0x7ffff7597b40,
expr=0x1621e38, stmts=0x7fffffffd7d8, domstmt=0x7ffff7eb7f50, type=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2777
#6 0x0000000000bd4409 in do_SCCVN_insertion (stmt=0x7ffff7eb7f50,
ssa_vn=0x7ffff759bb60)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:3761
#7 0x0000000000bd4816 in eliminate ()
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:3853
#8 0x0000000000bd5c0a in execute_pre (do_fre=1 '\001')
3848 tree val = VN_INFO (lhs)->valnum;
3849 if (val != VN_TOP
3850 && TREE_CODE (val) == SSA_NAME
3851 && VN_INFO (val)->needs_insertion
3852 && can_PRE_operation (vn_get_expr_for (val)))
3853 sprime = do_SCCVN_insertion (stmt, val);
3854 }
3855 if (sprime
3856 && sprime != lhs
3857 && (rhs == NULL_TREE
(gdb) call VN_INFO (val)
$1 = (struct vn_ssa_aux *) 0x1604aa0
(gdb) print *$1
$2 = {valnum = 0x7ffff759bb60, expr = 0x7ffff7599f00, value_id = 10,
dfsnum = 0, low = 0, visited = 0, on_sccstack = 0, has_constants = 0,
use_processed = 0, needs_insertion = 1}
(gdb) call debug_generic_expr (0x7ffff7599f00)
VIEW_CONVERT_EXPR<const unsigned char>(b_8)
b_8 is an enum of precision 32 (and thus not folded to a NOP_EXPR by fold).
But it looks like we miss a conversion and thus have an IL with invalid types
here from the start.
((const struct verteilung_c *) this)->bezug != 0 && ((const struct verteilung_c
*) this)->bezug != 69 ? ((const struct verteilung_c *) this)->bezug : b
<cond_expr 0x7ffff7ec1780
type <enumeral_type 0x7ffff758f540 kostenbezug_e unsigned SI
...
arg 0 <truth_and_expr 0x7ffff75993c0
type <boolean_type 0x7ffff7ebbb40 bool public unsigned QI
...
arg 1 <component_ref 0x7ffff7ec1730
type <integer_type 0x7ffff758fe40 unsigned char readonly public
unsigned string-flag QI size <integer_cst 0x7ffff7eb97b0 8> unit size
<integer_cst 0x7ffff7eb97e0 1>
...
arg 2 <parm_decl 0x7ffff7ec2bd0 b type <enumeral_type 0x7ffff758f540
kostenbezug_e>
...
with
<enumeral_type 0x7ffff758f540 kostenbezug_e unsigned SI
size <integer_cst 0x7ffff7eb9a50 type <integer_type 0x7ffff7ebb240
bit_size_type> constant 32>
which leads to invalid types after gimplification already. 4.3 is not
affected by the ICE.
The type-verifier is basically disabled on the trunk ... :/
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords| |ice-on-valid-code, wrong-
| |code
Known to work| |4.3.2
Last reconfirmed|0000-00-00 00:00:00 |2008-08-18 12:16:21
date| |
Summary|ICE - Compiler segfaults |[4.4 Regression] Invalid
| |types with COND_EXPR
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146
