[Bug fortran/57284] New: ICE with "find_array_spec: unused as (1)" in conjunction with size() intrinsic on class dummy parameter shape

[Bug fortran/57284] New: ICE with "find_array_spec: unused as (1)" in conjunction with size() intrinsic on class dummy parameter shape

[bugs at stellardeath dot org]

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

            Bug ID: 57284
           Summary: ICE with "find_array_spec: unused as (1)" in
                    conjunction with size() intrinsic on class dummy
                    parameter shape
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugs at stellardeath dot org

Created attachment 30119
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30119&action=edit
Minimal test case

I get an ICE for the following (valid?) minimal test-case involving a size()
intrinsic for a class() dummy argument:

> cat minimal.f90
module testmod
  type type_t
  end type type_t
  contains
  function foo(a, b) result(add)
    class(type_t), intent(in) :: a(:), b(size(a))
    type(type_t) :: add(size(a))
  end function
end module testmod
program p
  use testmod
end program
>
> ~/sys/bin/gfortran minimal.f90 
minimal.f90:10.9:

program p
         1
Internal Error at (1):
find_array_spec(): unused as(1)
>
> ~/sys/bin/gfortran --version
GNU Fortran (GCC) 4.9.0 20130514 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


Here, ~/sys/bin/gfortran is a self-compiled gfortran from yesterday's trunk,
the ICE also happens with the gfortran 4.7.2 supplied with openSUSE:


> gfortran --version
GNU Fortran (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012]
Copyright (C) 2012 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

> gfortran minimal.f90 
minimal.f90:10.9:

program p
         1
Internal Error at (1):
find_array_spec(): unused as(1)

[Bug fortran/57284] [OOP] ICE with "find_array_spec for polymorphic arrays

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |janus at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org
            Summary|ICE with "find_array_spec:  |[OOP] ICE with
                   |unused as (1)" in           |"find_array_spec  for
                   |conjunction with size()     |polymorphic arrays
                   |intrinsic on class dummy    |
                   |parameter shape             |

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The problem is that the expression is (internally):
   a->REF_COMPONENT("_data")->REF_ARRAY(full array)

In find_array_spec, the code firsts gets the array as:
   as = CLASS_DATA (e->symtree->n.sym)->as;

And then it walks the refs. Result:
   a->(full array)->_data->(full array)

But having two full arrays is invalid! Hence, it fails.

(find_array_spec doesn't see that the two arrays refs are identical.)

[Bug fortran/57284] [OOP] ICE with find_array_spec for polymorphic arrays

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-15
            Summary|[OOP] ICE with              |[OOP] ICE with
                   |"find_array_spec  for       |find_array_spec for
                   |polymorphic arrays          |polymorphic arrays
     Ever confirmed|0                           |1

[Bug fortran/57284] [OOP] ICE with find_array_spec for polymorphic arrays

[bugs at stellardeath dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284

--- Comment #3 from Lorenz Hüdepohl <bugs at stellardeath dot org> ---
Any progress on this one? 4.9.2 still produces the error:

> ~/sys/stow/gcc-4.9.2/bin/gfortran --version
GNU Fortran (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

> ~/sys/stow/gcc-4.9.2/bin/gfortran minimal.f90
minimal.f90:10.9:

program p
         1
Internal Error at (1):
find_array_spec(): unused as(1)
>From gcc-bugs-return-476496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 15:29:22 2015
Return-Path: <gcc-bugs-return-476496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6667 invoked by alias); 9 Feb 2015 15:29:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6606 invoked by uid 48); 9 Feb 2015 15:29:18 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64928] [4.8/4.9/5 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
Date: Mon, 09 Feb 2015 15:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: compile-time-hog, memory-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-64928-4-kWOP2rVIOZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64928-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64928-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00829.txt.bz2
Content-length: 1589

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd928

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
It seems that loop invariant motion is responsible for most of the abnormals,
thus -fno-tree-loop-im restores performance.

The loop LIM detects is of style

  <bb 6>: (header)
  # ___fp_3(ab) = PHI <___fp_41(4), ___fp_5(21)>
  # ___r1_7(ab) = PHI <___r1_42(4), ___r1_9(21)>
  # ___r2_11(ab) = PHI <___r2_43(4), ___r3_17(21)>
  # ___r3_19(ab) = PHI <___r3_44(4), ___r3_23(21)>
  # ___r4_25 = PHI <___r4_45(4), ___r4_26(21)>
  # gotovar.17_29 = PHI <_51(4), _69(21)>
  goto gotovar.17_29;

...

  <bb 21>: (latch)
  _67 = ___pc_1 + 15;
  _68 = (void * *) _67;
  _69 = *_68;
  PROF_edge_counter_142 = __gcov0.___H_object_2d__3e_u8vector[14];
  PROF_edge_counter_143 = PROF_edge_counter_142 + 1;
  __gcov0.___H_object_2d__3e_u8vector[14] = PROF_edge_counter_143;
  goto <bb 6>;

not sure if we should artificially limit such loops.  LIM doesn't account
for the (compile-time) cost of needing very many PHIs when rewriting
the store-motion vars into SSA form (but it could in theory estimate
by taking into account the CFG structure of the "loop").

Let's see if we can first generate a smaller testcase to illustrate the
issue.

Mine for now.