[Bug target/61058] New: [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[Bug target/61058] New: [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[zsojka at seznam dot cz]

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

            Bug ID: 61058
           Summary: [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected
                    elt 3 type 'B', have '0' (rtx barrier) in
                    distance_agu_use_in_bb, at config/i386/i386.c:16740
                    with __builtin_unreachable()
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz

Created attachment 32731
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32731&action=edit
reduced testcase

Compiler output:
$ gcc -fno-asynchronous-unwind-tables -mtune=atom testcase.c 
testcase.c: In function 'f':
testcase.c:4:1: internal compiler error: RTL check: expected elt 3 type 'B',
have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:17922
 }
 ^
0xac42d4 rtl_check_failed_type1(rtx_def const*, int, int, char const*, int,
char const*)
        /mnt/svn/gcc-trunk/gcc/rtl.c:754
0xdcc92a distance_agu_use_in_bb
        /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:17922
0xdd02e9 distance_agu_use
        /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:17979
0xdd02e9 ix86_lea_outperforms
        /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:18063
0xffa274 output_89
        /mnt/svn/gcc-trunk/gcc/config/i386/i386.md:2081
0x872491 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
        /mnt/svn/gcc-trunk/gcc/final.c:2919
0x873e3d final(rtx_def*, _IO_FILE*, int)
        /mnt/svn/gcc-trunk/gcc/final.c:2024
0x87434e rest_of_handle_final
        /mnt/svn/gcc-trunk/gcc/final.c:4428
0x87434e execute
        /mnt/svn/gcc-trunk/gcc/final.c:4502
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.

$ gcc -v                                                     
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.10.0 20140504 (experimental) (GCC) 

Built with RTL checking enabled.

Tested revisions:
r210047 - ICE
4.9 r209651 - ICE
4.8 r209342 - ICE
4.7 r209345 - ICE
4.6 r197894 - OK

[Bug target/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-checking
           Priority|P3                          |P2
   Target Milestone|---                         |4.7.4

[Bug target/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Similar to PR54455, where Steven said:

--q--
There can't be a BARRIER in the middle of a basic block. This problem typically
indicates that either a BARRIER was emitted in the wrong place, or BB_END
wasn't updated properly after a BARRIER was inserted somewhere. BARRIERs never
appear inside a basic block.
--/q--

The target ICEs due to invalid BARRIER location, so it looks like
rtl-optimization bug to me.
>From gcc-bugs-return-450561-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 05 09:47:11 2014
Return-Path: <gcc-bugs-return-450561-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29643 invoked by alias); 5 May 2014 09:47:11 -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 29285 invoked by uid 48); 5 May 2014 09:47:06 -0000
From: "christophe.lyon at st dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61062] vzip and vuzp execution tests fail on armeb
Date: Mon, 05 May 2014 09:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: christophe.lyon at st 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:
Message-ID: <bug-61062-4-fojDgoQOsj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61062-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61062-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: 2014-05/txt/msg00253.txt.bz2
Content-length: 1064

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

--- Comment #1 from christophe.lyon at st dot com ---
Similarly, vzup tests committed as SVN rev 209947 fail on armeb targets:
  gcc.target/arm/simd/vuzpf32_1.c execution test
  gcc.target/arm/simd/vuzpp16_1.c execution test
  gcc.target/arm/simd/vuzpp8_1.c execution test
  gcc.target/arm/simd/vuzpqf32_1.c execution test
  gcc.target/arm/simd/vuzpqp16_1.c execution test
  gcc.target/arm/simd/vuzpqp8_1.c execution test
  gcc.target/arm/simd/vuzpqs16_1.c execution test
  gcc.target/arm/simd/vuzpqs32_1.c execution test
  gcc.target/arm/simd/vuzpqs8_1.c execution test
  gcc.target/arm/simd/vuzpqu16_1.c execution test
  gcc.target/arm/simd/vuzpqu32_1.c execution test
  gcc.target/arm/simd/vuzpqu8_1.c execution test
  gcc.target/arm/simd/vuzps16_1.c execution test
  gcc.target/arm/simd/vuzps32_1.c execution test
  gcc.target/arm/simd/vuzps8_1.c execution test
  gcc.target/arm/simd/vuzpu16_1.c execution test
  gcc.target/arm/simd/vuzpu32_1.c execution test
  gcc.target/arm/simd/vuzpu8_1.c execution test

[Bug target/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #1)
> Similar to PR54455, where Steven said:
> 
> --q--
> There can't be a BARRIER in the middle of a basic block. This problem
> typically indicates that either a BARRIER was emitted in the wrong place, or
> BB_END wasn't updated properly after a BARRIER was inserted somewhere.
> BARRIERs never appear inside a basic block.
> --/q--
> 
> The target ICEs due to invalid BARRIER location, so it looks like
> rtl-optimization bug to me.

CC Jeff for confirmation.
>From gcc-bugs-return-450610-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 05 19:23:32 2014
Return-Path: <gcc-bugs-return-450610-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2596 invoked by alias); 5 May 2014 19:23:32 -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 2554 invoked by uid 48); 5 May 2014 19:23:29 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/61047] [4.9/4.10 Regression] wrong code at -O1 on x86_64-linux
Date: Mon, 05 May 2014 19:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-61047-4-IRSj1M3Atz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61047-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61047-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: 2014-05/txt/msg00302.txt.bz2
Content-length: 1940

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---

Prior to .ce3 we have:

(code_label 46 20 22 4 6 "" [1 uses])
(note 22 46 24 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 24 22 25 4 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:HI 0 ax [orig:97 ivtmp.14 ] [97])
            (const_int 2837 [0xb15]))) j.c:12 6 {*cmphi_1}
     (nil))
(jump_insn 25 24 26 4 (set (pc)
        (if_then_else (ne (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref 31)
            (pc))) j.c:12 596 {*jcc_1}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (int_list:REG_BR_PROB 7200 (nil)))
 -> 31)
;;  succ:       5 [28.0%]  (FALLTHRU)
;;              6 [72.0%]
;; lr  out       0 [ax] 1 [dx] 4 [si] 7 [sp]

;; basic block 5, loop depth 0, count 0, freq 1008, maybe hot
;;  prev block 4, next block 6, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:       4 [28.0%]  (FALLTHRU)
;; bb 5 artificial_defs: { }
;; bb 5 artificial_uses: { u-1(7){ }}
;; lr  in        0 [ax] 1 [dx] 4 [si] 7 [sp]
;; lr  use       7 [sp]
;; lr  def       2 [cx]
(note 26 25 28 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 28 26 73 5 (set (reg:SI 2 cx [orig:90 D.1786 ] [90])
        (mem/c:SI (plus:DI (reg/f:DI 7 sp)
                (const_int 11324 [0x2c3c])) [0  S4 A32])) j.c:13 90
{*movsi_internal}
     (nil))
(jump_insn 73 28 74 5 (set (pc)
        (label_ref 43)) 636 {jump}
     (nil)
 -> 43)

Note how the load at insn 28 is guarded by comparing ax against #2837.  CE3
transforms that into an unconditional load and we blow up reading the
out-of-range stack slot.

This isn't a threading issue, but a latent bug in CE as far as I can tell.

[Bug target/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jeffrey A. Law from comment #3)
> What do you need me to confirm?  I can confirm that you're not supposed to
> have BARRIERS in the middle of a block.

Confirmation of invalid barrier location, so this PR can be qualified as
rtl-optimization problem.

> 
> THe RTL in question:
> 
>         .file   "j.c"
>         .text
>         .globl  foo
>         .type   foo, @function
> foo:
>         pushq   %rbp
> (note 1 0 3 NOTE_INSN_DELETED)
> 
> (note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> 
> (insn/f 9 3 10 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
>         (reg/f:DI 6 bp)) j.c:2 65 {*pushdi2_rex64}
>      (nil))
> 
> (insn/f 10 9 5 2 (set (reg/f:DI 6 bp)
>         (reg/f:DI 7 sp)) j.c:2 89 {*movdi_internal}
>      (nil))
> 
> (barrier 5 10 11)
> 
> (note 11 5 2 2 NOTE_INSN_PROLOGUE_END)
> 
> (note 2 11 8 2 NOTE_INSN_FUNCTION_BEG)
> 
> (note 8 2 0 NOTE_INSN_DELETED)
> 
> 
> We're in distance_agu_use_in_bb.  We're passing it insn 10 as INSN and the
> BARRIER as START.   We try to look at BLOCK_FOR_INSN (start), after that,
> we're well into undefined territory.
> 
> But this really looks like x86 backend breakage. Refer to the above RTL and
> look at this call site:
> 
> 17976     if (insn != BB_END (bb))
> 17977       distance = distance_agu_use_in_bb (regno0, insn, distance,
> 17978                                          NEXT_INSN (insn),
> 17979                                          &found, &redefined);
> 
> Clearly if NEXT_INSN (insn) is a BARRIER, then nothing good can happen.

The accessors don't agree:

(gdb) p debug_rtx (insn)
(insn/f 10 9 5 2 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) pr61058.c:2 89 {*movdi_internal}
     (nil))
$3 = void
(gdb) p debug_rtx (bb->il.x.head_)
(note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
$4 = void
(gdb) p debug_rtx (bb->il.x.rtl->end_)
(note 2 11 8 2 NOTE_INSN_FUNCTION_BEG)
$5 = void

According to BB_END, which points to (note 2), barrier is inside block.
>From gcc-bugs-return-450620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 05 21:52:38 2014
Return-Path: <gcc-bugs-return-450620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11593 invoked by alias); 5 May 2014 21:52:37 -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 10830 invoked by uid 48); 5 May 2014 21:52:31 -0000
From: "tristanmoody at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61069] New: Gfortran allows functions to be called as subroutines when defined in a separate source file
Date: Mon, 05 May 2014 21:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tristanmoody 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-61069-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: 2014-05/txt/msg00312.txt.bz2
Content-length: 1904

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

            Bug ID: 61069
           Summary: Gfortran allows functions to be called as subroutines
                    when defined in a separate source file
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tristanmoody at gmail dot com

This might not be the easiest thing to fix, as (1) it appears that verifying
the semantics of a function call happen on a per-source-file basis, and (2)
there is no apparent way of marking a procedure as either a subroutine or a
function once it has been translated to assembly or object code.

Nevertheless, the problem is fairly straightforward.  Suppose there exists a
program "foo", as follows:

program foo
  implicit none
  integer :: i
  external bar, baz

  i = 0
  call bar(i)
  call baz(i)
end program

function bar(i)
  implicit none
  integer :: i
  integer :: bar

  bar = i + 10
  i = i + 5
  return
end function

subroutine baz(i)
  implicit none
  integer :: i

  write(*,*) i
  return
end subroutine


When the main program and the two subprograms are all in the same file, the
error is correctly caught by gfortran:

foobad.f90:8.13:

  call bar(i)
             1
foobad.f90:12.15:

function bar(i)
               2
Error: Global name 'bar' at (1) is already being used as a FUNCTION at (2)



However, when the main program is a separate file from the two subprograms,
(i.e. program foo in foo.f90, bar and baz in bar.f90, then compiled with
"gfortran foo.f90 bar.f90" ), then compilation proceeds without issue and the
resulting executable behaves as though bar() was called and its result
discarded.  Filing this bug report as this non-standard behavior does not
appear in any of the documentation I have seen.

[Bug rtl-optimization/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r181077.

[Bug rtl-optimization/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the buggy pass here is:
static unsigned int
cleanup_barriers (void)
{
  rtx insn, next, prev;
  for (insn = get_insns (); insn; insn = next)
    {
      next = NEXT_INSN (insn);
      if (BARRIER_P (insn))
        {
          prev = prev_nonnote_insn (insn);
          if (!prev) 
            continue;
          if (BARRIER_P (prev))
            delete_insn (insn);
          else if (prev != PREV_INSN (insn))
            reorder_insns_nobb (insn, insn, prev);
        }
    }
  return 0;
}

At the start of that pass we have:
(note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn/f 9 3 10 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
        (reg/f:DI 6 bp)) pr61058.c:3 -1
     (nil))
(insn/f 10 9 11 2 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) pr61058.c:3 -1
     (nil))
(note 11 10 2 2 NOTE_INSN_PROLOGUE_END)
(note 2 11 5 2 NOTE_INSN_FUNCTION_BEG)
(barrier 5 2 8)
(note 8 5 0 NOTE_INSN_DELETED)

where BB_HEAD (bb2) is note 3 and BB_END (bb2) is note 2, note 8 has been added
by LRA (but reload does that too AFAIK), both barrier and note are outside of
the bb 2.
Now, the above reorders the barrier after insn 10, making it part of bb2
because BB_END (bb2) isn't adjusted.

So, either cleanup_barriers should not move anything here (e.g. because prev
doesn't satisfy control_flow_insn_p (prev)), and/or, of it decides to move
something, it has to take care of adjusting the affected basic blocks (but how?
Would we keep the two notes (11 and 2) without basic block).
Do we need the cleanup_barriers pass at all these days?

[Bug rtl-optimization/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the other side, pass_cleanup_barriers is performed after pass_free_cfg, so
making it unconditionally cfg-aware is not going to work, it is just that i386
(as well as few other targets) calls compute_bb_for_insn in its mach_reorg pass
and doesn't free_bb_for_insn afterwards.  So perhaps do nothing if
BLOCK_FOR_INSN (prev), or call reorder_insns instead of reorder_insns_nobb if
BLOCK_FOR_INSN (prev)?  Though, calling reorder_insns there doesn't seem to
work either, it isn't prepared to handle the case of moving a BARRIER into the
middle of some bb.

[Bug rtl-optimization/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug rtl-optimization/61058] [4.8/4.9/5 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug rtl-optimization/61058] [4.8/4.9/5 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Jan 27 09:19:30 2015
New Revision: 220155

URL: https://gcc.gnu.org/viewcvs?rev=220155&root=gcc&view=rev
Log:
    PR rtl-optimization/61058
    * jump.c (cleanup_barriers): Update basic block boundaries
    if BLOCK_FOR_INSN is non-NULL on PREV.

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

Added:
    trunk/gcc/testsuite/gcc.dg/pr61058.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/jump.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61058] [4.8/4.9 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |5.0
            Summary|[4.8/4.9/5 Regression] ICE: |[4.8/4.9 Regression] ICE:
                   |RTL check: expected elt 3   |RTL check: expected elt 3
                   |type 'B', have '0' (rtx     |type 'B', have '0' (rtx
                   |barrier) in                 |barrier) in
                   |distance_agu_use_in_bb, at  |distance_agu_use_in_bb, at
                   |config/i386/i386.c:16740    |config/i386/i386.c:16740
                   |with                        |with
                   |__builtin_unreachable()     |__builtin_unreachable()
      Known to fail|4.10.0                      |

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

[Bug rtl-optimization/61058] [4.8/4.9 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Sun Feb  1 17:37:06 2015
New Revision: 220328

URL: https://gcc.gnu.org/viewcvs?rev=220328&root=gcc&view=rev
Log:
    Backported from mainline
    2015-01-27  Jakub Jelinek  <jakub@redhat.com>

    PR rtl-optimization/61058
    * jump.c (cleanup_barriers): Update basic block boundaries
    if BLOCK_FOR_INSN is non-NULL on PREV.

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

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61058.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/jump.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61058] [4.8/4.9 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Sun Feb  1 21:56:03 2015
New Revision: 220336

URL: https://gcc.gnu.org/viewcvs?rev=220336&root=gcc&view=rev
Log:
    Backported from mainline
    2015-01-27  Jakub Jelinek  <jakub@redhat.com>

    PR rtl-optimization/61058
    * jump.c (cleanup_barriers): Update basic block boundaries
    if BLOCK_FOR_INSN is non-NULL on PREV.

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

    2013-04-16  Steven Bosscher  <steven@gcc.gnu.org>

    PR middle-end/43631
    * jump.c (cleanup_barriers): Use reorder_insns_nobb to avoid making
    the moved barrier the tail of the basic block it follows.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr61058.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/jump.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61058] [4.8/4.9 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

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