------- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-26 10:57 -------
I see
(gdb) b error
Breakpoint 5 at 0x6a072d: file /space/rguenther/src/svn/trunk/gcc/diagnostic.c,
line 629.
(gdb) run
Breakpoint 5, error (
gmsgid=0x11a45c0 "type mismatch between an SSA_NAME and its symbol")
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:629
629 va_start (ap, gmsgid);
(gdb) up
#1 0x0000000000b99e0b in verify_ssa_name (ssa_name=0x7ffff5ae4d10,
is_virtual=0 '\000') at /space/rguenther/src/svn/trunk/gcc/tree-ssa.c:587
587 error ("type mismatch between an SSA_NAME and its symbol");
(gdb) l
582 return true;
583 }
584
585 if (TREE_TYPE (ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name)))
586 {
587 error ("type mismatch between an SSA_NAME and its symbol");
588 return true;
589 }
590
591 if (SSA_NAME_IN_FREE_LIST (ssa_name))
(gdb) p ssa_name->common.type
$1 = (tree) 0x7ffff7fcab28
(gdb) p ssa_name->ssa_name.var->common.type
$2 = (tree) 0x7ffff5ad9c78
(gdb) call debug_tree ($1)
<pointer_type 0x7ffff7fcab28
type <array_type 0x7ffff7fca540
type <real_type 0x7ffff7eee000 real(kind=4) SF
size <integer_cst 0x7ffff7ed2988 constant 32>
unit size <integer_cst 0x7ffff7ed2690 constant 4>
align 32 symtab 0 alias set 2 canonical type 0x7ffff7eee000
precision 32
pointer_to_this <pointer_type 0x7ffff7eee1f8> reference_to_this
<reference_type 0x7ffff7fc3a80>>
type_2 BLK
size <var_decl 0x7ffff7fc6500 D.1556 type <integer_type 0x7ffff7ee10a8
bit_size_type>
used unsigned ignored DI file t.f90 line 28 col 0
size <integer_cst 0x7ffff7ed2a50 constant 64>
unit size <integer_cst 0x7ffff7ed2a78 constant 8>
align 64 context <function_decl 0x7ffff7fc5800 anyavg> chain
<var_decl 0x7ffff7fc65a0 D.1557>>
unit size <var_decl 0x7ffff7fc65a0 D.1557 type <integer_type
0x7ffff7ee1000>
used unsigned ignored DI file t.f90 line 28 col 0 size <integer_cst
0x7ffff7ed2a50 64> unit size <integer_cst 0x7ffff7ed2a78 8>
align 64 context <function_decl 0x7ffff7fc5800 anyavg>>
align 32 symtab 0 alias set -1 canonical type 0x7ffff7fca540
domain <integer_type 0x7ffff7fcaf18 type <integer_type 0x7ffff7ee15e8
integer(kind=8)>
DI size <integer_cst 0x7ffff7ed2a50 64> unit size <integer_cst
0x7ffff7ed2a78 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff7fcaf18
precision 64 min <integer_cst 0x7ffff7ef1780 0> max <var_decl 0x7ffff7fc6460
D.1555>>
pointer_to_this <pointer_type 0x7ffff7fcaa80>>
unsigned restrict type_2 DI size <integer_cst 0x7ffff7ed2a50 64> unit size
<integer_cst 0x7ffff7ed2a78 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff7fcab28>
(gdb) call debug_tree ($2)
<pointer_type 0x7ffff5ad9c78
type <array_type 0x7ffff5ad9a80
type <real_type 0x7ffff7eee000 real(kind=4) SF
size <integer_cst 0x7ffff7ed2988 constant 32>
unit size <integer_cst 0x7ffff7ed2690 constant 4>
align 32 symtab 0 alias set 2 canonical type 0x7ffff7eee000
precision 32
pointer_to_this <pointer_type 0x7ffff7eee1f8> reference_to_this
<reference_type 0x7ffff7fc3a80>>
type_2 BLK
size <var_decl 0x7ffff5addb40 D.1623 type <integer_type 0x7ffff7ee10a8
bit_size_type>
used unsigned ignored DI file t.f90 line 28 col 0
size <integer_cst 0x7ffff7ed2a50 constant 64>
unit size <integer_cst 0x7ffff7ed2a78 constant 8>
align 64 context <function_decl 0x7ffff5ae1c00 anyavg.1546.clone.0>
abstract_origin <var_decl 0x7ffff7fc6500 D.1556>>
unit size <var_decl 0x7ffff5addaa0 D.1622 type <integer_type
0x7ffff7ee1000>
used unsigned ignored DI file t.f90 line 28 col 0 size <integer_cst
0x7ffff7ed2a50 64> unit size <integer_cst 0x7ffff7ed2a78 8>
align 64 context <function_decl 0x7ffff5ae1c00 anyavg.1546.clone.0>
abstract_origin <var_decl 0x7ffff7fc65a0 D.1557>>
align 32 symtab 0 alias set -1 canonical type 0x7ffff7fca540
domain <integer_type 0x7ffff5ad9b28 type <integer_type 0x7ffff7ee15e8
integer(kind=8)>
DI size <integer_cst 0x7ffff7ed2a50 64> unit size <integer_cst
0x7ffff7ed2a78 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff7fcaf18
precision 64 min <integer_cst 0x7ffff7ef1780 0> max <var_decl 0x7ffff5addbe0
D.1624>>
pointer_to_this <pointer_type 0x7ffff5ad9bd0>>
unsigned restrict DI size <integer_cst 0x7ffff7ed2a50 64> unit size
<integer_cst 0x7ffff7ed2a78 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff7fcab28>
so the difference is that the type of the SSA name has TYPE_LANG_FLAG_2
set for both the pointer and the array type while the SSA name variable
has not. They do both have the same canonical type (but not the same
main variants).
The SSA name type is built from
0x00000000005cc8b1 in gfc_get_nodesc_array_type (etype=0x7ffff7eee000,
as=0x17a7520, packed=PACKED_FULL, restricted=1 '\001')
at /space/rguenther/src/svn/trunk/gcc/fortran/trans-types.c:1530
1530 type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
while the variable type is built by the inliner at
0x0000000000d00ab3 in remap_type_1 (type=0x7ffff7fcab28, id=0x7fffffffd9d0)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:340
340 new_tree = build_type_attribute_qual_variant (new_tree,
Value returned is $20 = (union tree_node *) 0x7ffff5ad9c78
when remapping the type of (real(kind=4)[0:D.1555] * restrict) &gridws
The variable is built by the inliner at
0x0000000000d137e9 in copy_decl_to_var (decl=0x7ffff7eda5d8, id=0x7fffffffd9d0)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:4513
4513 copy = build_decl (DECL_SOURCE_LOCATION (id->dst_fn),
and has the type of the SSA name at that point. The SSA name is built
by the inliner at
0x0000000000cff96b in remap_ssa_name (name=0x7ffff7fcce70, id=0x7fffffffd9d0)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:214
214 new_tree = make_ssa_name (new_tree, NULL);
with the same type. The type of the variable is changed by
if (TREE_CODE (*tp) != OMP_CLAUSE)
TREE_TYPE (*tp) = remap_type (TREE_TYPE (*tp), id);
which is called from update_clone_info () called indirectly by
cgraph_materialize_clone ().
That one manages to mess up the types as it tries to update
replace_info->old_tree and replace_info->new_tree without realizing
that both of them hadn't been remapped. Instead of copying them
the routine should probably check if a mapping is registered for them
and only _then_ do the fixup. Or rather update_clone_info looks
broken by design. Why not pre-copy replace_info->new_tree and register
old_tree -> new_tree in the map? It doesn't make sense to update
replace_info->old_tree anyway as the tree has been replaced. But
maybe I am missing something.
-fno-ipa-cp fixes the testcase. As does
Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c (revision 157746)
+++ gcc/tree-inline.c (working copy)
@@ -4729,8 +4729,8 @@ update_clone_info (copy_body_data * id)
{
struct ipa_replace_map *replace_info;
replace_info = VEC_index (ipa_replace_map_p,
node->clone.tree_map, i);
- walk_tree (&replace_info->old_tree, copy_tree_body_r, id, NULL);
- walk_tree (&replace_info->new_tree, copy_tree_body_r, id, NULL);
+ if (replace_info->replace_p)
+ walk_tree (&replace_info->new_tree, copy_tree_body_r, id,
NULL);
}
}
if (node->clones)
Honza/Martin - I really cannot make sense of the above function.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu dot
| |org, jamborm at gcc dot gnu
| |dot org
Component|fortran |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
