From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17025 invoked by alias); 30 Jul 2014 19:11: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 Received: (qmail 16981 invoked by uid 48); 30 Jul 2014 19:11:33 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/61968] New: ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE Date: Wed, 30 Jul 2014 19:11: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.10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org 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 keywords bug_severity priority component assigned_to reporter cc attachments.created Message-ID: 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-07/txt/msg02003.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61968 Bug ID: 61968 Summary: ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE Product: gcc Version: 4.10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jnorris at gcc dot gnu.org, pault at gcc dot gnu.org Created attachment 33216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D33216&action=3Dedit Testcase (test.f90) Passing a TYPE(*) to CLASS(*) is properly rejected by the compiler, thus, t= here is no need to attempt to generate a virtual table for TYPE(*) =E2=80=93 ign= oring the problem that TYPE(*) has no real type. My suspicion is that this happens during resolving the generic call, trigge= red by the CLASS - even though the actual class call isn't and shouldn't be don= e. The generated function looks in assembly as follows - unsurprisingly, the assembler stumbles over it: .type __copy_TYPE(*)_0_.2366, @function Credit for finding the issue goes to Jim. >>From gcc-bugs-return-457413-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 30 19:48:02 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 18706 invoked by alias); 30 Jul 2014 19:48:02 -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 18591 invoked by uid 48); 30 Jul 2014 19:47:58 -0000 From: "Joost.VandeVondele at mat dot ethz.ch" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/61933] Inquire on internal units Date: Wed, 30 Jul 2014 19:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch 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: cc dependson Message-ID: In-Reply-To: References: 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-07/txt/msg02004.txt.bz2 Content-length: 1234 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933 Joost VandeVondele changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Joost.VandeVondele at mat dot ethz | |.ch, jvdelisle at gcc dot gnu.org Depends on| |33055 --- Comment #1 from Joost VandeVondele --- actually, looking into preparing a patch for this I figured this is related to the old PR33055, and I would argue that the fix for that PR is incorrect... give n the quote from the standard. Also, it leads to surprising behavior: LOGICAL :: file_exists INTEGER :: istat CHARACTER(LEN=5) :: t istat=-42 INQUIRE(UNIT=-1,EXIST=file_exists,IOSTAT=istat) WRITE(6,*) file_exists,istat END now istat will be non-zero, but the inquire without istat will not generate a runtime error, nor jump to the ERR label if that would be present instead. The behavior can be understood seeing the use of create_dummy_iostat in trans-io.c, IMO a hack to catch this case.