public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugs at stellardeath dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/57461] New: Ice on valid: lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file Date: Wed, 29 May 2013 22:35:00 -0000 [thread overview] Message-ID: <bug-57461-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57461 Bug ID: 57461 Summary: Ice on valid: lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file 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 30220 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30220&action=edit "Minimal" test case, has to be named e.g. input.f90 (or another 5char + ".f90" name) to trigger the ICE Trying out a self-compiled gfortran from a few days ago (see below for --version), I stumbled upon an ICE on the attached (apparently) valid code. The ice only happens with _all_ of the following flags: -fbounds-check -finit-real=snan -g3 -fopenmp Unfortunately, the "minimal" example I reduced out of our code (~10000 lines) with "delta" is with 484 lines still rather large. Is seems mostly to contain an object-oriented module used for timings and some of our helper functions to abort the program with debug prints. Note that the ICE seems incredibly sensitive, when I tried to manually simplify the example code, I discovered that if I do any of the following, the ICE disappears: - Remove the empty and unused module "foomod" in the first few lines - Rewrite the subroutine "raise_warning_x" to only accept one argument - Change the name of the subroutine "foobar_pwr2" to "foobar_pwr" - Remove any of the compilation flags given above What struck me as most odd: - If I renamed the file from input.f90 to minimal.f90, it compiled! I experimented a bit with this, and the filename seems to have to be 5 characters + ".f90", otherwise it compiles... I really hope anyone can reproduce this bug :) (I could trigger it on at least 3 different machines, however it was always a self-compiled version from trunk, maybe I screwed something up there.) Here is the output of a compilation (see attached file for input.f90): > gfortran -fbounds-check -finit-real=snan -g3 -fopenmp -c input.f90 input.f90:293.16: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer input.f90:235.16: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer input.f90:258.22: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer input.f90: In function ‘btr_solve’: input.f90:438:0: internal compiler error: Segmentation fault end subroutine btr_solve ^ 0x9f09ef crash_signal ../.././gcc/toplev.c:333 0x6ab923 lookup_page_table_entry ../.././gcc/ggc-page.c:593 0x6ab923 ggc_set_mark(void const*) ../.././gcc/ggc-page.c:1467 0x89e311 gt_ggc_mx_loop(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:893 0x89da69 gt_ggc_mx_basic_block_def(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:1415 0x89dfc9 gt_ggc_mx_gimple_statement_d(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:1515 0x89f561 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:612 0x89f545 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:610 0x89f545 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:610 0x89f545 gt_ggc_mx_cgraph_edge(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:610 0x89f183 gt_ggc_mx_symtab_node_def(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:717 0x89f630 gt_ggc_m_P15symtab_node_def4htab(void*) /home/lorenz/src/gcc/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:2908 0x850bd5 ggc_mark_root_tab ../.././gcc/ggc-common.c:133 0x850ed0 ggc_mark_roots() ../.././gcc/ggc-common.c:152 0x6abffe ggc_collect() ../.././gcc/ggc-page.c:2077 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. > > gfortran --version GNU Fortran (GCC) 4.9.0 20130523 (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 > This is what happens for a non 5char + ".f90" filename: > cp input.f90 minimal.f90 > gfortran -fbounds-check -finit-real=snan -g3 -fopenmp -c minimal.f90 minimal.f90:293.16: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer minimal.f90:235.16: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer minimal.f90:258.22: !$ do i = 0, omp_get_level() 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer > Note that the ICE disappears if I declare omp_get_level via "use omp_lib" (as was done in our original code). In the reduced file it seems that this has to be removed to trigger the ICE. I hope you can learn anything from this rather complex case, Lorenz >From gcc-bugs-return-423400-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu May 30 00:01:08 2013 Return-Path: <gcc-bugs-return-423400-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 7747 invoked by alias); 30 May 2013 00:01:08 -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 7706 invoked by uid 48); 30 May 2013 00:01:03 -0000 From: "josh.m.conner at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/57462] New: ira-costs considers only a single register at a time Date: Thu, 30 May 2013 00:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: josh.m.conner at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: <bug-57462-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: 2013-05/txt/msg02073.txt.bz2 Content-length: 3528 http://gcc.gnu.org/bugzilla/show_bug.cgi?idW462 Bug ID: 57462 Summary: ira-costs considers only a single register at a time Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: josh.m.conner at gmail dot com In this code: int PopCnt(unsigned long long a, unsigned long long b) { register int c=0; while(a) { c++; a &= a + b; } return(c); } Built for ARM with: gcc test.c -O2 -S -o test.s The code generated for the loop is: .L3: fmdrr d18, r0, r1 @ int vadd.i64 d16, d18, d17 fmrrd r4, r5, d16 @ int and r0, r0, r4 and r1, r1, r5 orrs r5, r0, r1 add r3, r3, #1 bne .L3 There is quite a bit of gymnastics in order to use the FP registers for the add instruction. The code is simpler if all registers are allocated to integer registers: .L3: adds r2, r4, r6 adc r3, r5, r7 and r4, r4, r2 and r5, r5, r3 orrs r3, r4, r5 add r0, r0, #1 bne .L3 The code is shorter, and doesn't include the potentially-expensive FP<=>INT register move operations. *** The rest of this bug is my analysis, providing an explanation of why I have put this bug into the rtl-optimization category. The problem I see is that the register classifier (ira-costs.c) makes decisions on register classes for each register in relative isolation, without adequately considering the impact of that decision on other registers. In this example, we have 3 main registers we're concerned with: a, b, and a temporary register (ignoring c, which we don't need to consider). The code when costs are calculated is roughly: tmp = a + b a = a & tmp CC = compare (a, 0) Both the adddi3 and anddi3 operations can be performed in either integer or FP regs, with a preference for the FP regs because the sequence is shorter (1 insn instead of 2). The compare operation can only be performed in an integer register. In the first pass of the cost analysis: "a" is assigned to the integer registers, since the cheaper adddi/anddi operations are outweighed by the cost of having to move the value from FP=>INT for the compare. "b" and "tmp" are both assigned to FP registers, since they are only involved in operations that are cheaper with the FP hardware. In the second pass of the cost analysis, each register is again analyzed independently: "a" is left in the integer register because moving it to a FP register would add an additional FP=>INT move for the compare. "b" and "tmp" are both left in FP registers because moving either one would still leave us with mixed FP/INT operations. The biggest problem I see is that the first pass should recognize that since "a" must be in an integer register, there is an unconsidered cost to putting "b" and "tmp" in FP registers since they are involved in instructions where the operands must be in the same register class. A lesser, and probably more difficult, problem is that the second pass could do better if it would consider changing register classes of more than one register at a time. This seems potentially complex, but perhaps we could just consider register pairs that are involved in instructions with mismatched operand classes, where the combination is invalid for the instruction.
next reply other threads:[~2013-05-29 22:35 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-29 22:35 bugs at stellardeath dot org [this message] 2013-05-30 6:48 ` [Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in " burnus at gcc dot gnu.org 2013-05-30 7:51 ` dominiq at lps dot ens.fr 2013-05-30 8:20 ` burnus at gcc dot gnu.org 2013-09-26 6:12 ` Joost.VandeVondele at mat dot ethz.ch 2013-10-30 12:35 ` rguenth at gcc dot gnu.org 2013-10-30 12:41 ` Joost.VandeVondele at mat dot ethz.ch 2013-11-22 10:47 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-57461-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).