public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/61968] New: ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
@ 2014-07-30 19:11 burnus at gcc dot gnu.org
2014-08-16 12:20 ` [Bug fortran/61968] " dominiq at lps dot ens.fr
2015-10-10 8:57 ` dominiq at lps dot ens.fr
0 siblings, 2 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-07-30 19:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
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=33216&action=edit
Testcase (test.f90)
Passing a TYPE(*) to CLASS(*) is properly rejected by the compiler, thus, there
is no need to attempt to generate a virtual table for TYPE(*) – ignoring the
problem that TYPE(*) has no real type.
My suspicion is that this happens during resolving the generic call, triggered
by the CLASS - even though the actual class call isn't and shouldn't be done.
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: <gcc-bugs-return-457413-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 18591 invoked by uid 48); 30 Jul 2014 19:47:58 -0000
From: "Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>
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: <bug-61933-4-tsNoort9c7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61933-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61933-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-07/txt/msg02004.txt.bz2
Content-length: 1234
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida933
Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 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 <Joost.VandeVondele at mat dot ethz.ch> ---
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-10-10 8:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-30 19:11 [Bug fortran/61968] New: ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE burnus at gcc dot gnu.org
2014-08-16 12:20 ` [Bug fortran/61968] " dominiq at lps dot ens.fr
2015-10-10 8:57 ` dominiq at lps dot ens.fr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).