[Bug fortran/57461] New: Ice on valid: lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[Bug fortran/57461] New: Ice on valid: lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[bugs at stellardeath dot org]

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.

[Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-30
                 CC|                            |burnus at gcc dot gnu.org
          Component|fortran                     |middle-end
            Summary|Ice on valid:               |[4.9 Regression] ICE
                   |lookup_page_table_entry,    |(segfault) for pass_final's
                   |depending on details like   |ggc_collect: in
                   |(length of?) identifier     |lookup_page_table_entry,
                   |names, file name of source  |depending on details like
                   |file                        |(length of?) identifier
                   |                            |names, file name of source
                   |                            |file
     Ever confirmed|0                           |1

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Confirmed. Works for me with GCC 4.8 and fails with 4.9.

The problem is that "table" == NULL for:

lookup_page_table_entry (p=0xafafafaf0000000f) at ../../gcc/ggc-page.c:593
593       while (table->high_bits != high_bits)

[Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
There is no ICE if gcc is configured with --enable-checking=release. The ICE is
present for revision 198804 (2013-05-12), but not for revision 196555 (4.8,
2013-03-08).

[Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |4.9.0

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Bisecting points at http://gcc.gnu.org/r198966

r198966 | jakub | 2013-05-16 12:43:33 +0200 (Do, 16. Mai 2013) | 19 Zeilen

        * omp-low.c (extract_omp_for_data): For collapsed loops,
        if at least one of the loops is known at compile time to
        iterate zero times, set count to 0.
        (expand_omp_regimplify_p): New function.
        (expand_omp_for_generic): For collapsed loops, if at least
        one of the loops isn't known to iterate at least once,
        add runtime check with setting count to 0.
        (expand_omp_for_static_nochunk, expand_omp_for_static_chunk):
        For unsigned types if it isn't known at compile time that
        the loop will iterate at least once, add runtime check to bypass
        the whole loop if initial condition isn't true.

[Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat dot ethz
                   |                            |.ch

--- Comment #4 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
This is a reduced testcase from PR58024, which is very likely a dup, however,
it is much smaller:

Using 

 gfortran -c -fopenmp  --param=ggc-min-heapsize=0 --param=ggc-min-expand=0 
bug.f90


subroutine factorize_slu_r ()
  factor_loop : do
     !$OMP PARALLEL DO SCHEDULE (DYNAMIC) PRIVATE (info)
     reduce_loop : do k = 1, n-l, 2*l
  if(.NOT. (info >= 0)) then
    stop
  endif
     end do reduce_loop
  end do factor_loop
end subroutine factorize_slu_r


bug.f90: In function ‘factorize_slu_r’:
bug.f90:10:0: internal compiler error: Segmentation fault
 end subroutine factorize_slu_r
 ^
0x9bbe5f crash_signal
    ../../gcc/gcc/toplev.c:334
0x661303 lookup_page_table_entry
    ../../gcc/gcc/ggc-page.c:593
0x661303 ggc_set_mark(void const*)
    ../../gcc/gcc/ggc-page.c:1467
>From gcc-bugs-return-430585-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 26 06:13:49 2013
Return-Path: <gcc-bugs-return-430585-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26649 invoked by alias); 26 Sep 2013 06:13:49 -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 26525 invoked by uid 48); 26 Sep 2013 06:13:46 -0000
From: "Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file
Date: Thu, 26 Sep 2013 06:13: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.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-57461-4-bxME5mOANM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57461-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57461-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-09/txt/msg01825.txt.bz2
Content-length: 479

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW461

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |townsend at astro dot wisc.edu

--- Comment #5 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
*** Bug 58024 has been marked as a duplicate of this bug. ***

[Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can't reproduce it with the reduced testcase, so fixed?

[Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #7 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Richard Biener from comment #6)
> I can't reproduce it with the reduced testcase, so fixed?

Magically fixed, also the original ones.. maybe add the reduced testcase to the
testsuite ?

[Bug middle-end/57461] [4.9 Regression] ICE (segfault) for pass_final's ggc_collect: in lookup_page_table_entry, depending on details like (length of?) identifier names, file name of source file

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.