• 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 ..

    @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)
  • 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 ..


    @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)
  • From Paul Richard Thomas@21:1/5 to All on Thu Dec 15 08:09:19 2022
    Hi Amir,

    I have taken a long break from gfortran support because the daytime job has been demanding a lot of time. My intention is to complete the work on finalization that I started in the first quarter of this year. Reworking PDTs is the next large task.
    Unfortunately, it really will be a reworking since the representation of the PDTs does not support fixes for the most important bugs. That said, most of the mechanisms need to do the job are in place. I fear that you will have to watch this space but I
    do not see any prospects for progress until well into 2023.

    I do apologise for taking so long to reply. I haven't even been monitoring c.l.f.

    Regards

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Paul Richard Thomas on Thu Dec 15 09:07:54 2022
    On Thursday, December 15, 2022 at 11:09:22 AM UTC-5, Paul Richard Thomas wrote:

    .. I fear that you will have to watch this space but I do not see any prospects for progress until well into 2023.
    ..

    @Paul Richard Thomas,

    Thank you very much for your effort.

    You may also want to announce this at the Fortran Discourse site: https://fortran-lang.discourse.group/

    Since you will find a lot of gfortran users also at the Fortran Discourse site, if you can do anything to entice, teach, mentor, guide such users to collaborate with you on gfortran patches, you can really advance gfortran further and more and more users
    can become contributors who can maintain and carry forward your legacy with gfortran.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Amir Shahmoradi@21:1/5 to FortranFan on Tue Dec 20 12:01:53 2022
    Dear Paul, Thank you very much for your reply and continued efforts. As FortranFan said, the community appreciates every second of your time on improving gfortran and helping a new generation of gfortran contributors get started on the path that you,
    Kargl, and others have pioneered.
    ~Amir

    On Thursday, December 15, 2022 at 11:07:57 AM UTC-6, FortranFan wrote:
    On Thursday, December 15, 2022 at 11:09:22 AM UTC-5, Paul Richard Thomas wrote:

    .. I fear that you will have to watch this space but I do not see any prospects for progress until well into 2023.
    ..

    @Paul Richard Thomas,

    Thank you very much for your effort.

    You may also want to announce this at the Fortran Discourse site: https://fortran-lang.discourse.group/

    Since you will find a lot of gfortran users also at the Fortran Discourse site, if you can do anything to entice, teach, mentor, guide such users to collaborate with you on gfortran patches, you can really advance gfortran further and more and more
    users can become contributors who can maintain and carry forward your legacy with gfortran.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Richard Thomas@21:1/5 to All on Sun Jan 8 10:03:30 2023
    Dear Amil,

    While Steve and I have been involved for a long time, I must play tribute to the founding trio, who built gfortran from scratch to the point, where it was a viable f95 compiler and was worth the efforts of successive waves of maintainers: Andy Vaught (
    for the front end, which produces the intermediate representation), Paul Brook and Steven Bosscher (for the translation of the intermediate representation to TREE_SSA, which then plugs into the gcc infrastucture). Toon Moene's support on the gcc Steering
    Committee and testing to destruction of gfortran has been invaluable from the start.

    Work started on gfortran, or g95 as was before the branch, in 1989. The first gcc ChangeLog is 2002 and is dominated by Paul and Steven. Steve Kargl's first entry is in June 2003. Of the presently active maintainers, Thomas Koenig, Jerry Delisle ,
    Francois-Xavier Coudert and I do not appear until 2005. 2004/5 saw a large growth in the number of people contributing patches so that by the mid-naughties gfortran's f95 coverage was solid. Major f2003 features began to appear in the last half of that
    decade, with Daniel Kraft introducing the FINAL declaration in 2008, Janus Weil introducing polymorphism in 2009 and Parameterized Derived Types by me in 2017. Polymorphism and OOP steadily improved in a few years after it's introduction to the point
    where it could be relied upon. Finalization received a big boost in 2012 with Tobias Burnus's monumental "finalization_wrapper" but implementation remains incomplete to this day and is awaiting my recently posted patch for completion of Daniel and Tobias'
    s work. I fear that, as described earlier in this thread, implementation of PDTs is fundamentally flawed. Thus it is unlikely that full f2003 compliance will be achieved until some time in 2023!

    One might reasonably ask why there has been such a slow development towards f2003 compliance, even. I might be speculating somewhat but it seems to me that it is largely, for the main part, due to the motivation of the volunteer maintainers to add or
    improve features that are compatible with commercial vendors' offerings and reasonably reliable in all platforms. As the number of such features has fallen away, so have the contributors to gfortran. With a few exceptions, nearly all the work on gfortran
    since 2002 or 3 has been done on a voluntary, unpaid basis to meet immediate needs required to support specific coding needs. Such has been the weak demand for much beyond f95 that many of the commercial vendors ceased or slowed development and then fell
    by the wayside. Familiarity with C++ and/or the appearance of the likes of python meant that OOP support in gfortran grew relatively rapidly, the demand for consistent support for finalization has really only surfaced in recent years and PDTs are lagging
    further behind.

    Thus, in my humble opinion, the "new generation of gfortran contributors" will only emerge if they are motivated either by need or are being paid to support gfortran. We give every assistance that that we can to newbies but our ability to do so is
    typically limited by our daytime jobs. That the gfortran compiler is written in C, with a tiny touch of C++, has also proven to be a barrier. All my younger colleagues are brought up to write their codes in Matlab/Octave or python and only delve into
    fortran when they have to and so the pool is ever diminishing.

    If anybody wants a helping hand to write patches to fix bugs or add new features, please write to the gfortran list or get in touch with Jerry Delisle to join us on https://gfortran.cloud.mattermost.com/.

    Best regards

    Paul

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