https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108663
--- Comment #7 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> --- Hi Steve, The trouble with that is that all the operator generation is done automatically. One you have declared mytype, you get an internal name of Mytype and an operator called mytype. I didn't want to mess with that. Oddly, I tried "Pdt@" as the prefix and it breaks all sorts of things and without a load of investigation, I have no inkling as to why that is. I am going to tackle the PR at the stage of building the use only list. There is no reason at all why that couldn't flag up an error. Equally, I have ensured that PDT instances are taken on board, when the template name is used. That said, if a user decides to declare both derived type pdtmytype and a PDT mytype with no KIND parameters there will be a conflict. Maybe a message should be provided to say the the gfortran implementation doesn't allow that? I have eliminated most of the PDT bugs that I can before PR82649 has to be tackled, which requires a change of backend representation... I rather think (there is a possible kludge). As it is, for most folk the 16-branch implementation of PDTs is usable, Flang cannot handle LEN parameters and ifx has errors with some conforming code in the same places as mainline. I felt honour bound to deal with PDTs sometime because I left such a dog's dinner with the first version. Truth be told, Damian Rouson's rather extreme exploitation of PDTs has been very helpful, not just for gfortran but for ifx and, especially, for flang. He tells me that the interaction with the other two compiler teams has been just as intense as with Jerry and me. There is a developing battle over templates in F202y, which will I think provoke a split between flang and just about every other vendor. I cannot see how gfortran maintainers can possibly find the resources to implement the US proposal for templates, whereas we do stand a fighting chance with the Japanese proposal. This is especially the case while Steve Lionel is convenor of WG5 since he is one of the owners of the GPL is bad mantra. Either way, templates will make PDTs seem like a walk in the park and leads me to believe that if you want that stuff, use C++. Rant over Regards Paul On Fri, 12 Dec 2025 at 21:35, sgk at troutmask dot apl.washington.edu < [email protected]> wrote: > 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. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug.
