[Bug c++/98331] New: [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845

[Bug c++/98331] New: [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845

[gscfq@t-online.de]

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

            Bug ID: 98331
           Summary: [9/10/11 Regression] ICE in haifa_luid_for_non_insn,
                    at haifa-sched.c:7845
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Following combination of options affects several files from
gcc/testsuite at -O2+, e.g. pr69589_0.C, builtin_unreachable-1.c,
devirt-52.C, ... (regression date depends on testfile) :


$ g++-11-20201213 -c pr69589_0.C -g -O2 -m32 -fopenmp -fprofile-generate
pr69589_0.C: In member function 'Z<S, B<S> > C<int>::m8() const':
pr69589_0.C:22:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   22 | }
      | ^
during RTL pass: sched2
pr69589_0.C:22:1: internal compiler error: in haifa_luid_for_non_insn, at
haifa-sched.c:7845
0x1556e06 haifa_luid_for_non_insn
        ../../gcc/haifa-sched.c:7845
0x155d809 sched_init_insn_luid(rtx_insn*)
        ../../gcc/haifa-sched.c:8977
0x155de2a sched_init_luids(vec<basic_block_def*, va_heap, vl_ptr>)
        ../../gcc/haifa-sched.c:9006
0x155e0dc haifa_sched_init()
        ../../gcc/haifa-sched.c:7382
0xc46d1a schedule_insns()
        ../../gcc/sched-rgn.c:3514
0xc473fd schedule_insns()
        ../../gcc/sched-rgn.c:3508
0xc473fd rest_of_handle_sched2
        ../../gcc/sched-rgn.c:3746
0xc473fd execute
        ../../gcc/sched-rgn.c:3882

---

pr69589_0.C: In member function 'Z<S, B<S> > C<int>::m8() const':
pr69589_0.C:22:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   22 | }
      | ^
during RTL pass: expand
pr69589_0.C:22:1: internal compiler error: Segmentation fault
0xf86f4f crash_signal
        ../../gcc/toplev.c:327
0xaa7913 rtl_verify_bb_pointers
        ../../gcc/cfgrtl.c:2780
0xaa7913 rtl_verify_flow_info_1
        ../../gcc/cfgrtl.c:2832
0xaa84b2 rtl_verify_flow_info
        ../../gcc/cfgrtl.c:3076
0xa8879a verify_flow_info()
        ../../gcc/cfghooks.c:267
0x19920e6 checking_verify_flow_info
        ../../gcc/cfghooks.h:212
0x19920e6 try_optimize_cfg
        ../../gcc/cfgcleanup.c:3009
0x1992513 cleanup_cfg(int)
        ../../gcc/cfgcleanup.c:3174
0xa85841 execute
        ../../gcc/cfgexpand.c:6884

[Bug c++/98331] [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-12-17
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
            Summary|[9/10/11 Regression] ICE in |[9/10/11 Regression] ICE in
                   |haifa_luid_for_non_insn, at |haifa_luid_for_non_insn, at
                   |haifa-sched.c:7845          |haifa-sched.c:7845 since
                   |                            |r8-5479-g67a8d7199fe4e474
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r8-5479-g67a8d7199fe4e474.

[Bug c++/98331] [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.4

[Bug c++/98331] [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/98331] [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase, only -g -O2 -m32 -march=x86-64 is needed:
void bar (const char *);
unsigned long long x;

void
foo (void)
{
  bar ("foo");
  __atomic_fetch_add (&x, 1, 0);
  __builtin_unreachable ();
}

[Bug c++/98331] [8/9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |8.5
             Status|NEW                         |ASSIGNED
            Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE
                   |haifa_luid_for_non_insn, at |in haifa_luid_for_non_insn,
                   |haifa-sched.c:7845 since    |at haifa-sched.c:7845 since
                   |r8-5479-g67a8d7199fe4e474   |r8-5479-g67a8d7199fe4e474
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
When I slightly tweak the testcase, it started with
r8-3191-gc5f597633467c2fc0fa80afa19c99f049fac8466

void bar (const char *);
unsigned long long x;

void
foo (void)
{
  int a = 1;
  bar ("foo");
  int b = 2;
  __atomic_fetch_add (&x, 1, 0);
  int c = 3;
  __builtin_unreachable ();
}

[Bug debug/98331] [8/9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50073&action=edit
gcc11-pr98331.patch

Untested fix.  If there are debug insns in between a flow control insn and
barrier after it and that barrier is later followed by some normal insn other
than label (i.e. dead insn), without -g we'd split after the barrier, which
puts the barrier in between bbs.
But with -g, the code would incorrectly split before the first debug insn
following the control flow, which results in a barrier inside of a bb rather
than in between and also different behavior from -g0.
If there are debug insns after the barrier, we should obviously split before
the first of those debug insns (i.e. after the barrier) like we'd do with -g0.

[Bug debug/98331] [8/9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9c445c07cda60488d7a5458b070356e05e7b2e09

commit r11-6969-g9c445c07cda60488d7a5458b070356e05e7b2e09
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 29 10:30:09 2021 +0100

    expand: Fix up find_bb_boundaries [PR98331]

    When expansion emits some control flow insns etc. inside of a former GIMPLE
    basic block, find_bb_boundaries needs to split it into multiple basic
    blocks.
    The code needs to ignore debug insns in decisions how many splits to do or
    where in between some non-debug insns the split should be done, but it can
    decide where to put debug insns if they can be kept and otherwise throws
    them away (they can't stay outside of basic blocks).
    On the following testcase, we end up in the bb from expander with
    control flow insn
    debug insns
    barrier
    some other insn
    (the some other insn is effectively dead after __builtin_unreachable and
    we'll optimize that out later).
    Without debug insns, we'd do the split when encountering some other insn
    and split after PREV_INSN (some other insn), i.e. after barrier (and the
    splitting code then moves the barrier in between basic blocks).
    But if there are debug insns, we actually split before the first debug insn
    that appeared after the control flow insn, so after control flow insn,
    and get a basic block that starts with debug insns and then has a barrier
    in the middle that nothing moves it out of the bb.  This leads to ICEs and
    even if it wouldn't, different behavior from -g0.
    The reason for treating debug insns that way is a different case, e.g.
    control flow insn
    debug insns
    some other insn
    or even
    control flow insn
    barrier
    debug insns
    some other insn
    where splitting before the first such debug insn allows us to keep them
    while otherwise we would have to drop them on the floor, and in those
    situations we behave the same with -g0 and -g.

    So, the following patch fixes it by resetting debug_insn not just when
    splitting the blocks (it is set only after seeing a control flow insn and
    before splitting for it if needed), but also when seeing a barrier,
    which effectively means we always throw away debug insns after a control
    flow insn and before following barrier if any, but there is no way around
    that, control flow insn must be the last in the bb (BB_END) and BARRIER
    after it, debug insns aren't allowed outside of bb.
    We still handle the other cases fine (when there is no barrier or when
    debug insns appear only after the barrier).

    2021-01-29  Jakub Jelinek  <jakub@redhat.com>

            PR debug/98331
            * cfgbuild.c (find_bb_boundaries): Reset debug_insn when seeing
            a BARRIER.

            * gcc.dg/pr98331.c: New test.

[Bug debug/98331] [8/9/10 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
                   |in haifa_luid_for_non_insn, |haifa_luid_for_non_insn, at
                   |at haifa-sched.c:7845 since |haifa-sched.c:7845 since
                   |r8-5479-g67a8d7199fe4e474   |r8-5479-g67a8d7199fe4e474

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug debug/98331] [8/9/10 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:ea0e1eaa30f42e108f6c716745347cc1dcfdc475

commit r10-9324-gea0e1eaa30f42e108f6c716745347cc1dcfdc475
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 29 10:30:09 2021 +0100

    expand: Fix up find_bb_boundaries [PR98331]

    When expansion emits some control flow insns etc. inside of a former GIMPLE
    basic block, find_bb_boundaries needs to split it into multiple basic
    blocks.
    The code needs to ignore debug insns in decisions how many splits to do or
    where in between some non-debug insns the split should be done, but it can
    decide where to put debug insns if they can be kept and otherwise throws
    them away (they can't stay outside of basic blocks).
    On the following testcase, we end up in the bb from expander with
    control flow insn
    debug insns
    barrier
    some other insn
    (the some other insn is effectively dead after __builtin_unreachable and
    we'll optimize that out later).
    Without debug insns, we'd do the split when encountering some other insn
    and split after PREV_INSN (some other insn), i.e. after barrier (and the
    splitting code then moves the barrier in between basic blocks).
    But if there are debug insns, we actually split before the first debug insn
    that appeared after the control flow insn, so after control flow insn,
    and get a basic block that starts with debug insns and then has a barrier
    in the middle that nothing moves it out of the bb.  This leads to ICEs and
    even if it wouldn't, different behavior from -g0.
    The reason for treating debug insns that way is a different case, e.g.
    control flow insn
    debug insns
    some other insn
    or even
    control flow insn
    barrier
    debug insns
    some other insn
    where splitting before the first such debug insn allows us to keep them
    while otherwise we would have to drop them on the floor, and in those
    situations we behave the same with -g0 and -g.

    So, the following patch fixes it by resetting debug_insn not just when
    splitting the blocks (it is set only after seeing a control flow insn and
    before splitting for it if needed), but also when seeing a barrier,
    which effectively means we always throw away debug insns after a control
    flow insn and before following barrier if any, but there is no way around
    that, control flow insn must be the last in the bb (BB_END) and BARRIER
    after it, debug insns aren't allowed outside of bb.
    We still handle the other cases fine (when there is no barrier or when
    debug insns appear only after the barrier).

    2021-01-29  Jakub Jelinek  <jakub@redhat.com>

            PR debug/98331
            * cfgbuild.c (find_bb_boundaries): Reset debug_insn when seeing
            a BARRIER.

            * gcc.dg/pr98331.c: New test.

[Bug debug/98331] [8/9 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
                   |haifa_luid_for_non_insn, at |haifa_luid_for_non_insn, at
                   |haifa-sched.c:7845 since    |haifa-sched.c:7845 since
                   |r8-5479-g67a8d7199fe4e474   |r8-5479-g67a8d7199fe4e474

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.3+ too.

[Bug debug/98331] [8/9 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b717d2be2c1ec177488d2af8c63f441810fd0e29

commit r9-9413-gb717d2be2c1ec177488d2af8c63f441810fd0e29
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 29 10:30:09 2021 +0100

    expand: Fix up find_bb_boundaries [PR98331]

    When expansion emits some control flow insns etc. inside of a former GIMPLE
    basic block, find_bb_boundaries needs to split it into multiple basic
    blocks.
    The code needs to ignore debug insns in decisions how many splits to do or
    where in between some non-debug insns the split should be done, but it can
    decide where to put debug insns if they can be kept and otherwise throws
    them away (they can't stay outside of basic blocks).
    On the following testcase, we end up in the bb from expander with
    control flow insn
    debug insns
    barrier
    some other insn
    (the some other insn is effectively dead after __builtin_unreachable and
    we'll optimize that out later).
    Without debug insns, we'd do the split when encountering some other insn
    and split after PREV_INSN (some other insn), i.e. after barrier (and the
    splitting code then moves the barrier in between basic blocks).
    But if there are debug insns, we actually split before the first debug insn
    that appeared after the control flow insn, so after control flow insn,
    and get a basic block that starts with debug insns and then has a barrier
    in the middle that nothing moves it out of the bb.  This leads to ICEs and
    even if it wouldn't, different behavior from -g0.
    The reason for treating debug insns that way is a different case, e.g.
    control flow insn
    debug insns
    some other insn
    or even
    control flow insn
    barrier
    debug insns
    some other insn
    where splitting before the first such debug insn allows us to keep them
    while otherwise we would have to drop them on the floor, and in those
    situations we behave the same with -g0 and -g.

    So, the following patch fixes it by resetting debug_insn not just when
    splitting the blocks (it is set only after seeing a control flow insn and
    before splitting for it if needed), but also when seeing a barrier,
    which effectively means we always throw away debug insns after a control
    flow insn and before following barrier if any, but there is no way around
    that, control flow insn must be the last in the bb (BB_END) and BARRIER
    after it, debug insns aren't allowed outside of bb.
    We still handle the other cases fine (when there is no barrier or when
    debug insns appear only after the barrier).

    2021-01-29  Jakub Jelinek  <jakub@redhat.com>

            PR debug/98331
            * cfgbuild.c (find_bb_boundaries): Reset debug_insn when seeing
            a BARRIER.

            * gcc.dg/pr98331.c: New test.

    (cherry picked from commit ea0e1eaa30f42e108f6c716745347cc1dcfdc475)

[Bug debug/98331] [8/9 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:8cc0976478d298d587969a48de0e168f7f09fa36

commit r8-10879-g8cc0976478d298d587969a48de0e168f7f09fa36
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 29 10:30:09 2021 +0100

    expand: Fix up find_bb_boundaries [PR98331]

    When expansion emits some control flow insns etc. inside of a former GIMPLE
    basic block, find_bb_boundaries needs to split it into multiple basic
    blocks.
    The code needs to ignore debug insns in decisions how many splits to do or
    where in between some non-debug insns the split should be done, but it can
    decide where to put debug insns if they can be kept and otherwise throws
    them away (they can't stay outside of basic blocks).
    On the following testcase, we end up in the bb from expander with
    control flow insn
    debug insns
    barrier
    some other insn
    (the some other insn is effectively dead after __builtin_unreachable and
    we'll optimize that out later).
    Without debug insns, we'd do the split when encountering some other insn
    and split after PREV_INSN (some other insn), i.e. after barrier (and the
    splitting code then moves the barrier in between basic blocks).
    But if there are debug insns, we actually split before the first debug insn
    that appeared after the control flow insn, so after control flow insn,
    and get a basic block that starts with debug insns and then has a barrier
    in the middle that nothing moves it out of the bb.  This leads to ICEs and
    even if it wouldn't, different behavior from -g0.
    The reason for treating debug insns that way is a different case, e.g.
    control flow insn
    debug insns
    some other insn
    or even
    control flow insn
    barrier
    debug insns
    some other insn
    where splitting before the first such debug insn allows us to keep them
    while otherwise we would have to drop them on the floor, and in those
    situations we behave the same with -g0 and -g.

    So, the following patch fixes it by resetting debug_insn not just when
    splitting the blocks (it is set only after seeing a control flow insn and
    before splitting for it if needed), but also when seeing a barrier,
    which effectively means we always throw away debug insns after a control
    flow insn and before following barrier if any, but there is no way around
    that, control flow insn must be the last in the bb (BB_END) and BARRIER
    after it, debug insns aren't allowed outside of bb.
    We still handle the other cases fine (when there is no barrier or when
    debug insns appear only after the barrier).

    2021-01-29  Jakub Jelinek  <jakub@redhat.com>

            PR debug/98331
            * cfgbuild.c (find_bb_boundaries): Reset debug_insn when seeing
            a BARRIER.

            * gcc.dg/pr98331.c: New test.

    (cherry picked from commit ea0e1eaa30f42e108f6c716745347cc1dcfdc475)

[Bug debug/98331] [8/9 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.