[Bug fortran/108663] Accepts invalid bug with pdtXXX

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Dec 12, 2025 at 05:21:46PM +0000, pault at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108663
> 
> --- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
> (In reply to Steve Kargl from comment #1)
> > > $ gfortran-13-20221218 -c z1.f90   # missing error
> > > $
> > > $ gfortran-13-20230115 -c z1.f90
> > > z1.f90:12:7:
> > > 
> > >    12 |    use m, only: t, pdtt, s
> > >       |       1
> > > internal compiler error: in check_complete_insertion, at hash-table.h:578
> > 
> > For the record, the entity 'pdtt' is not specified
> > in the module.  It is constructed by gfortran in 
> > decl.cc(gfc_get_pdt_instance) when parsing a parameterized
> > derived type.  The symbol pdtt means PDT type t, and it
> > appears to inserted into the namespace.  A likely better
> > name would have been _PDT_t, because the leading underscore
> > means the name cannot conflict with a user's code and
> > gfortran downcases all parsed code so PDT shows that the
> > symbol is artificial.
> 
> The trouble with a leading non-alpha character is that U/C vs. L/C is used to
> distinguish the derived type vs the constructor.
> 
> I have been trying to think of a suitable separator between the "Pdt" prefix
> and the rest of the name.
> 
> Can you remember why '.' was deemed to be unsuitable for class names?
> 

>From a Fortran J3 standard point, I suspect that they
were worried about possible ambiguities with user defined
operators.  With name mangling of module procedures, 
gfortran uses inserts in a name _MOD_, which cannot conflict
with user code as gfortran downcases all tokens.  I don't
the internals of pdt too well; using pdt_dt_ and pdt_con_ to
distinguish derive type and constructor.