[Bug fortran/61968] New: ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.