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.
