• Re: Parameterized Derived Types make first appearance in gfortran 8.0.0

    From Amir Shahmoradi@21:1/5 to paul.rich...@gmail.com on Sun Mar 13 18:30:13 2022
    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 ..


    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


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

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

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

    call sub( foo )

    --- end code ---

    Upon compilation,
    gfortran.exe -c p.f90
    call sub( foo )
    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.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to paul.rich...@gmail.com on Sun Mar 13 19:55:29 2022
    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 ..


    Here's another issue, a nastier one involving an internal compiler error, from a case tried by James Van Buskirk:

    --- 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 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)

    fails in the same way.
    Try using PL/I.
    chr = 'x'; is sufficient.

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