[Bug tree-optimization/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3

["paul dot richard dot thomas at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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-bugzilla@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