From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 69CE33858C5F; Tue, 21 Mar 2023 19:28:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69CE33858C5F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1679426885;
	bh=J+xSbTfOx8pXkbZoF2RN8mVwzbvGADaQH+FEerT7MQc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=VtVstmooxk4v0lInhMtI+Obs9o/4ZEB+Gw3HMH2sbWTkviZ1VP1jVYZLV18+OCZom
	 ARZaZkph880iT1v6IpmGIpi64Nu+/w63PDPjWgUiTeuxZKU1m8RCETk9Mu7haMyOl4
	 jcCmgeNkH7HOPZVwW89RDq/Fw22L2/r6dtYTskiM=
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/109223] parameters for a type on IMPLICIT do not work.
 For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
Date: Tue, 21 Mar 2023 19:28:05 +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: 12.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
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: 
Message-ID: <bug-109223-4-BTsIFWBH9U@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109223-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109223-4@http.gcc.gnu.org/bugzilla/>
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
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109223

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> -=
--
On Tue, Mar 21, 2023 at 02:57:49PM +0000, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109223
>=20
> --- Comment #5 from kargl at gcc dot gnu.org ---
> (In reply to urbanjost from comment #4)
> > User-defined types work and as I read the ISO standard are supported, a=
nd
> > TYPE(REAL) works; it is only when a parameter is added that it fails;
> > nvfortran fails for user-defined type declared below it but it works wi=
th
> > one defined via a USE from a module; while gfortran allows the type to =
be
> > defined after the use,
> > but I consider that a nvfortran bug myself.=20
>=20
> Ah, yeah, you're right.  I failed to follow the EBNF in R864.
> It seems that gfortran is getting tripped up with the character
> following the basic type name, ie., the kind selector part.
>=20


So, there is a chunk of code in decl.cc(4682-4689 or so),

  if (implicit_flag =3D=3D 1)
    {
        if (matched_type && gfc_match_char (')') !=3D MATCH_YES)
          return MATCH_ERROR;

        return MATCH_YES;
    }

causing the problem.  The implicit_flag =3D=3D 1 conditional was
added in 2004 (revision e5ddaa24beae) to check for 'IMPLICIT
CHARACTER'.  The code block was updated in revision 0fb56814562a
when 'TYPE(intrinsic-type-spec)' was added to gfortran.

I have no idea how this was suppose to work.=