From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16648 invoked by alias); 5 May 2014 21:06:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 16607 invoked by uid 48); 5 May 2014 21:06:35 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [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() Date: Mon, 05 May 2014 21:06: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: ice-checking, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail 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.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-05/txt/msg00311.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61058 --- Comment #4 from Uro=C5=A1 Bizjak --- (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. >=20 > THe RTL in question: >=20 > .file "j.c" > .text > .globl foo > .type foo, @function > foo: > pushq %rbp > (note 1 0 3 NOTE_INSN_DELETED) >=20 > (note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK) >=20 > (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)) >=20 > (insn/f 10 9 5 2 (set (reg/f:DI 6 bp) > (reg/f:DI 7 sp)) j.c:2 89 {*movdi_internal} > (nil)) >=20 > (barrier 5 10 11) >=20 > (note 11 5 2 2 NOTE_INSN_PROLOGUE_END) >=20 > (note 2 11 8 2 NOTE_INSN_FUNCTION_BEG) >=20 > (note 8 2 0 NOTE_INSN_DELETED) >=20 >=20 > 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. >=20 > But this really looks like x86 backend breakage. Refer to the above RTL a= nd > look at this call site: >=20 > 17976 if (insn !=3D BB_END (bb)) > 17977 distance =3D distance_agu_use_in_bb (regno0, insn, distance, > 17978 NEXT_INSN (insn), > 17979 &found, &redefined); >=20 > 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 =3D void (gdb) p debug_rtx (bb->il.x.head_) (note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK) $4 =3D void (gdb) p debug_rtx (bb->il.x.rtl->end_) (note 2 11 8 2 NOTE_INSN_FUNCTION_BEG) $5 =3D 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: 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: List-Archive: List-Post: List-Help: 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" 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: 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?id=61069 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.