------- Comment #7 from paul dot richard dot thomas at gmail dot com
2010-03-26 11:08 -------
Subject: Re: [4.5 Regression] type mismatch
between an SSA_NAME and its symbol with -O3
Richi, Thanks for intervening. Paul
On Fri, Mar 26, 2010 at 11:57 AM, rguenth at gcc dot gnu dot org
<gcc-bugzi...@gcc.gnu.org> wrote:
>
>
> ------- 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
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505
