[Bug fortran/43505] New: [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3

[Bug fortran/43505] New: [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3

[pault at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

The testcase below is a development of that in PR41056 comment #8.  It,
however, does not need -fwhole-file to trigger the ICE. The ICE does not occur
with GNU Fortran (GCC) 4.4.4 20100314 (prerelease).  It also does not occur if
the declaration for 'gridws' is moved to main.  Therefore, it is somehow
related to the fact that 'gridws' is use associated. 

[pault@localhost pr41056]# /irun/bin/gfortran -static  -O3 pr*6a.f90
pr41056a.f90: In function ‘anyavg.1546.clone.0’:
pr41056a.f90:28:0: error: type mismatch between an SSA_NAME and its symbol
while verifying SSA_NAME hts_1 in statement
hts_1 = (real(kind=4)[0:D.1555] * restrict) &gridws;
pr41056a.f90:28:0: error: type mismatch between an SSA_NAME and its symbol
pr41056a.f90:28:0: error: in statement
hts_1 = (real(kind=4)[0:D.1555] * restrict) &gridws;
pr41056a.f90:28:0: internal compiler error: verify_ssa failed

Cheers

Paul

    MODULE MAIN1
      INTEGER , PARAMETER :: MXGLVL = 87
      CHARACTER(8) :: SRCTYP
      REAL :: GRIDWS(MXGLVL)
      REAL :: ZI, HS
    END MODULE MAIN1

    PROGRAM TEST
      USE MAIN1
      IF (HS >= ZI) THEN
      ELSEIF (      SRCTYP == 'AREA'     &
               .OR. SRCTYP == 'AREAPOLY' &
               .OR. SRCTYP == 'AREACIRC' &
               .OR. SRCTYP == 'OPENPIT'   ) THEN
         CALL ANYAVG (MXGLVL, GRIDWS)
         CALL ANYAVG (MXGLVL, GRIDWS)
      ELSE
         IF ( HS > 0.0 ) THEN
            CALL ANYAVG (MXGLVL, GRIDWS)
            CALL ANYAVG (MXGLVL, GRIDWS)
            CALL ANYAVG (MXGLVL, GRIDWS)
         ENDIF
      ENDIF
      IF (HS.LT.ZI) THEN
         ZI = HS
      ENDIF
    contains
      SUBROUTINE ANYAVG(NLVLS,HTS)
        INTEGER NLVLS
        REAL HTS(NLVLS)
        IF (5.LT.NLVLS) THEN
           CALL GINTRP (HTS(5),HTS(5+1))
        ENDIF
        CALL GINTRP (HTS(5-1), HTS(5))
      END SUBROUTINE ANYAVG

      subroutine gintrp (x1, x2)
        print *, x1, x2
      end subroutine

    END PROGRAM TEST


-- 
           Summary: [4.5 Regression] type mismatch between an SSA_NAME and
                    its symbol with -O3
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pault at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-24 09:52 -------
Hm, but the error is about hts_1, not gridws.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-checking
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-24 09:52:14
               date|                            |
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[pault at gcc dot gnu dot org]

------- Comment #2 from pault at gcc dot gnu dot org  2010-03-24 11:09 -------
(In reply to comment #1)
> Hm, but the error is about hts_1, not gridws.
> 

Does that not merely reflect the order that they are checked in the assignment?

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[rguenther at suse dot de]

------- Comment #3 from rguenther at suse dot de  2010-03-24 11:30 -------
Subject: Re:  [4.5 Regression] type mismatch between an
 SSA_NAME and its symbol with -O3

On Wed, 24 Mar 2010, pault at gcc dot gnu dot org wrote:

> ------- Comment #2 from pault at gcc dot gnu dot org  2010-03-24 11:09 -------
> (In reply to comment #1)
> > Hm, but the error is about hts_1, not gridws.
> > 
> 
> Does that not merely reflect the order that they are checked in the assignment?

No, the checking complains that TREE_TYPE (hts_1) (the type of the
SSA name) is != TREE_TYPE (hts) (its symbol).  That should never happen.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[pault at gcc dot gnu dot org]

------- Comment #4 from pault at gcc dot gnu dot org  2010-03-24 11:39 -------
(In reply to comment #3)

> No, the checking complains that TREE_TYPE (hts_1) (the type of the
> SSA name) is != TREE_TYPE (hts) (its symbol).  That should never happen.

Ah, OK.

Interestingly, when HTS is declared assumed size or assumed shape, the ICE does
not occur, as in PR41056.  The inlining proceeds as far as calls to gintrp.  If
gridws is not use associated, gintrp is inlined too.  I admit, however, that
this is a distraction from the problem with hts.

The difficulty must lie with the typing of address expressions in gfortran.
I'll have a further think about it tonight.

Any advice that you can give would be gratefully received.  The critical bit is
in trans.c:gfc_build_addr_expr.

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[pault at gcc dot gnu dot org]

------- Comment #5 from pault at gcc dot gnu dot org  2010-03-25 21:59 -------
I am a bit lost :-(

(gdb) print ssa_name->common
$6 = {base = {code = SSA_NAME, side_effects_flag = 0, constant_flag = 0, 
    addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
    unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
    used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
    private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
    saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
    lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
    lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
    user_align = 0, spare = 0, address_space = 0}, chain = 0x0, 
  type = 0x7f9172eced20}
(gdb) print ssa_name->ssa_name.var->common
$7 = {base = {code = VAR_DECL, side_effects_flag = 0, constant_flag = 0, 
    addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
    unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
    used_flag = 1, nothrow_flag = 0, static_flag = 1, public_flag = 0, 
    private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
    saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
    lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
    lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
    user_align = 0, spare = 0, address_space = 0}, chain = 0x0, 
  type = 0x7f9172eced20}

I presume that one being an SSA_NAME and the other being a VAR_DECL is how it
is supposed to be?  Other than that, the types are identical, aren't they?

Equally, eliminating
  if (TREE_TYPE (ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name)))
    {
      error ("type mismatch between an SSA_NAME and its symbol");
      return true;
    }

in tree-ssa.c:verify_ssa_name fixes the problem.

So, we have a sanity check that has no effect that I can see.  Where do these
things get set in the first place?

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[rguenth at gcc dot gnu dot org]

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

[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]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9628 bytes --]



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

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

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-26 15:10 -------
*** Bug 41056 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominiq at lps dot ens dot
                   |                            |fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[hubicka at gcc dot gnu dot org]

------- Comment #9 from hubicka at gcc dot gnu dot org  2010-03-27 18:30 -------
Have patch in testing. Problem is that inliner is copying the clone info
including the replacement when producing clone of clone that leads to
transformations sometimes being applied multiple times.


-- 

hubicka at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-03-24 09:52:14         |2010-03-27 18:30:42
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505

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

[hubicka at gcc dot gnu dot org]

------- Comment #10 from hubicka at gcc dot gnu dot org  2010-03-28 21:47 -------
Subject: Bug 43505

Author: hubicka
Date: Sun Mar 28 21:46:50 2010
New Revision: 157786

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157786
Log:

        PR tree-optimization/43505
        * cgraph.c (cgraph_clone_node): When clonning a clone, replacement
        map should not be copied.
        * gfortran.dg/pr43505.f90: New testcase.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr43505.f90
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraph.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43505