From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7279 invoked by alias); 9 Feb 2015 15:18:09 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 7224 invoked by uid 48); 9 Feb 2015 15:18:04 -0000 From: "bugs at stellardeath dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/57284] [OOP] ICE with find_array_spec for polymorphic arrays Date: Mon, 09 Feb 2015 15:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: bugs at stellardeath dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg00828.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57284 --- Comment #3 from Lorenz H=C3=BCdepohl --- 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=64928 Richard Biener 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 --- 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 : (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; ... : (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 ; 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.