[Bug fortran/109223] New: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[Bug fortran/109223] New: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[urbanjost at comcast dot net]

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

            Bug ID: 109223
           Summary: parameters for a type on IMPLICIT do not work. For
                    example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: urbanjost at comcast dot net
  Target Milestone: ---

This fails on the IMPLICIT statement

      program testit
      use, intrinsic :: iso_fortran_env, only : qp=>real128
      implicit type(real(kind=qp)) (a-z) ! this should work but fails
      ! surprising (to me) this works, which I thought broke the syntax rules
      ! implicit real(kind=qp) (a-z)       
      type(real(kind=QP)) :: quad
         print '(*(g0))', "kind(long) = ", kind(long), &
         & "; expected is ", kind(quad)
      end program testit

The expected output is

      kind(long) = 16; expected is 16

The "Fortran Standard" implies type parameters are standard:

      8.7      IMPLICIT statement
      1 In a scoping unit, an IMPLICIT statement specifies a type, and possibly
        type parameters, for all implicitly typed data entities whose names
        begin with one of the letters specified in the statement. An IMPLICIT
        NONE statement can indicate that no implicit typing rules are to apply
        in a particular scoping unit, or that external and dummy procedures
        need to be explicitly given the EXTERNAL attribute.

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[urbanjost at comcast dot net]

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

--- Comment #1 from urbanjost at comcast dot net ---
*** Bug 109226 has been marked as a duplicate of this bug. ***

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Why do you think it should work?

R863 implicit-stmt       is IMPLICIT implicit-spec-list
                         or IMPLICIT NONE [ ( [ implicit-none-spec-list ] ) ]

R864 implicit-spec       is declaration-type-spec ( letter-spec-list )

R865 letter-spec         is letter [-­ letter ]

R866 implicit-none-spec  is EXTERNAL
                         or TYPE

My reading of the EBNF is that TYPE can only following NONE.
Your code lacks NONE.

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Why do you think it should work?
> 
> R863 implicit-stmt       is IMPLICIT implicit-spec-list
>                          or IMPLICIT NONE [ ( [ implicit-none-spec-list ] ) ]
> 
> R864 implicit-spec       is declaration-type-spec ( letter-spec-list )
> 
> R865 letter-spec         is letter [-­ letter ]
> 
> R866 implicit-none-spec  is EXTERNAL
>                          or TYPE
> 
> My reading of the EBNF is that TYPE can only following NONE.
> Your code lacks NONE.

Replying to self.  In fact, the syntax requires (TYPE) not TYPE.
More importantly TYPE does not take a declaration-type-spec.

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[urbanjost at comcast dot net]

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

--- Comment #4 from urbanjost at comcast dot net ---
User-defined types work and as I read the ISO standard are supported, and
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 with 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. 

Rereading the spec "type" and "type arguments" could be interpreted as meaning
just something like "REAL(KIND=QP) (A)" which does work, but I do not see where
the excludes "TYPE(REAL(QP))", particularly since "TYPE(REAL)" and all other
type declaration syntax appears to work?

program testit
use, intrinsic :: iso_fortran_env, only :
real_kinds,sp=>real32,dp=>real64,qp=>real128
implicit type(null) (a)
implicit type(real) (f)  
implicit real(dp) (d)  
!implicit type(real(kind=qp)) (c) ! <== OK in a declaration, error in IMPLICIT
type null
end type null
! the syntax works for a declaration
type(real)          :: float_default
type(real(kind=sp)) :: float
type(real(kind=dp)) :: long
type(real(kind=qp)) :: quad
end program testit

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[kargl at gcc dot gnu.org]

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

--- 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, and
> 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 with
> 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. 

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.

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[sgk at troutmask dot apl.washington.edu]

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

--- 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=109223
> 
> --- 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, and
> > 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 with
> > 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. 
> 
> 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.
> 


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

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

        return MATCH_YES;
    }

causing the problem.  The implicit_flag == 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.

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Mar 21, 2023 at 12:27:58PM -0700, Steve Kargl wrote:
> 
> So, there is a chunk of code in decl.cc(4682-4689 or so),
> 
>   if (implicit_flag == 1)
>     {
> 	if (matched_type && gfc_match_char (')') != MATCH_YES)
> 	  return MATCH_ERROR;
> 
> 	return MATCH_YES;
>     }
> 
> causing the problem.  The implicit_flag == 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.

Well, I figured that out.  The code allows

'implicit real (a-z)'

to be parsed and compiled.  The downside is that it
blocks OP's code.  A simplied code

program testit
!  implicit real    (a-z)           ! Works
!  implicit real(4) (a-z)           ! Works
   implicit type(real(4)) (a-z)     ! Whoops.
   type(real(4)) :: quad
   if (kind(quad) /= 4) stop 1
end program testit

So, 'type(intrinsic-type-spec)' seems to be broken
when placed in 'implicit type(intrinsic-type-spec)'.

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-03-22
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4

--- Comment #8 from kargl at gcc dot gnu.org ---
Confirmed.