[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" <gcc-bugzilla@gcc.gnu.org>]

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.