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.
