Dear Paul, First, I want to thank you for leading the PDT development efforts. It's a feat, especially given the unusual implementation complexities of PDTs.
Given that you have led much (or all) of the gfortran PDT development efforts, do you have any insights into the latest status of PDTs in gfortran 12 and its development timeline (in particular, fixing the kind type parameter bugs)?

I was redirected to this page by FortranFan (in response to my question about the status and the future of PDTs in gfortran here: https://groups.google.com/g/comp.lang.fortran/c/xwg5Ak-EwHc).

The kind type parameter is crucial for generic derived types and the existing PDT bugs in gfortran have slowed down the progress of our research project (other compilers have full nearly-bug-free implementations of PDTs), but we strive to keep the
gfortran support along with other compilers.

I'd love to get involved and help the development of PDTs as much as my other obligations allow me. But in doing so, I need someone who can guide me (and others interested) along the way as I currently have zero experience with gfortran internals and the
inner workings of PDTs. Perhaps this could be turned into a 2022 Google-Summer-of-Code project if it is not too late already.

Thanks again,
Amir S.


On Monday, January 1, 2018 at 12:07:41 PM UTC-6, paul.rich...@gmail.com wrote:

On Sunday, 31 December 2017 04:10:14 UTC, FortranFan wrote:

On Saturday, December 2, 2017 at 2:27:49 PM UTC-5, paul.rich...@gmail.com wrote:

..
Apart from this, there are issues with type matching in interface comparisons ..

@Paul,

Thanks much for all your effort. Wish you many more retreats to enjoy that lead to many more blessings for the FOSS developers!

Re: your comment above with "issues with type matching in interface comparisons", you may want to consider the test case below as well:

--- begin code snippet ---
module m

type :: t(ell)
integer, len :: ell
integer :: i(ell)
end type

contains

subroutine sub( a )
type(t(ell=*)), intent(inout) :: a
end

end module m
! main program
use m, only : t, sub

type(t(ell=42)) :: foo

call sub( foo )

end
--- end code ---

Upon compilation,
gfortran.exe -c p.f90
p.f90:20:18:
call sub( foo )
1
Error: Type mismatch in argument 'a' at (1); passed TYPE(Pdtt) to TYPE(pdtt)

Aaaah, its's the 'only' that has done that. I need to make sure that 't' is expanded to encompass the PDT instances in the USE statement.

This is now PR83646.

Thanks

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, November 6, 2017 at 12:08:10 AM UTC+11, paul.rich...@gmail.com wrote:

On Tuesday, 31 October 2017 20:23:43 UTC, FortranFan wrote:

On Wednesday, September 13, 2017 at 2:04:28 PM UTC-4, paul.rich...@gmail.com wrote:

..

Since you provided me with a rather useful testcase later in this thread ..

@Paul,

Here's another issue, a nastier one involving an internal compiler error, from a case tried by James Van Buskirk:
https://groups.google.com/d/msg/comp.lang.fortran/7QJAwoKN4Jw/kLuSid-VCgAJ

--- begin code ---
type :: t(ell)
integer, len :: ell
character(len=1) :: s(ell)
end type

integer, parameter :: N = 2
type(t(ell=:)), allocatable :: foo

allocate( t(ell=N) :: foo )
foo%s = transfer(source=repeat("x",ncopies=N), mold=[ character(len=1) :: ], size=N)

end
--- end code ---

Compilation output:

gfortran.exe -c p.f90 -o p.o
f951.exe: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

This is a problem with the simplification of transfer:
integer, parameter :: N = 2
character(len=1) :: chr(N)
chr = transfer(source=repeat("x",ncopies=N), mold=[ character(len=1) :: ], size=N)
end

fails in the same way.

.
Try using PL/I.
chr = 'x'; is sufficient.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)