Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Parameterized Derived Types make first appearance in gfortran 8.0.0

1,893 views
Skip to first unread message

paul.rich...@gmail.com

unread,
Sep 9, 2017, 11:35:51 AM9/9/17
to
Dear All,

I have just applied a patch to GNU Fortran (GCC) 8.0.0 20170909 (experimental) which implements Parameterized Derived Types.

This implementation is still somewhat rough around the edges and so I would greatly appreciate bug reports, preferably to gcc Bugzilla with the title prefaced by "PDT" or directly to me.

The five testcases pdt_[1-5].f03 will give an impression of the state of implementation.

Regards

Paul


paul.rich...@gmail.com

unread,
Sep 9, 2017, 2:30:29 PM9/9/17
to
I forgot to add an appreciation to the Sourcery Institute and Damian Rouson, in particular, for support for this work.

Thanks guys!

Paul

FortranFan

unread,
Sep 9, 2017, 4:25:35 PM9/9/17
to
On Saturday, September 9, 2017 at 11:35:51 AM UTC-4, paul.rich...@gmail.com wrote:

> ..
>
> I have just applied a patch to GNU Fortran (GCC) 8.0.0 20170909 (experimental) which implements Parameterized Derived Types.
>
> ..

@Paul,

Mighty congratulations!

Thank you for your great effort, it is a wonderful achievement, bringing GNU Fortran (GCC) ever closer to a full-feature Fortran 2003 compiler if at all there are any aspects still pending from that iconic standard revision following your latest work on PDTs!

If you and your GCC colleagues can conjure up extra magic and effort, GNU Fortran can be a full-feature Fortran 2015 compiler next year, just when the standard is 'officially' published during August 2018 (per https://wg5-fortran.org/f2015.html). That is, once you have "climbed the mountain" in terms of Coarrays, PDTs, and SUBMODULEs, the pending features from the two supposed minor revisions of 2008 and 2015 will not faze you!

Wow, 2015 by 2018! Now that's a target to shoot for!

Many thanks,

FortranFan

unread,
Sep 9, 2017, 4:31:49 PM9/9/17
to
On Saturday, September 9, 2017 at 2:30:29 PM UTC-4, paul.rich...@gmail.com wrote:

> ..
>
> I forgot to add an appreciation to the Sourcery Institute and Damian Rouson, in particular, for support for this work.
>
> Thanks guys!
> ..

Kudos to Damian Rouson and the Sourcery Institute, great contribution to the advancement of Fortran.

Much appreciated,

FortranFan

unread,
Sep 9, 2017, 5:00:37 PM9/9/17
to
On Saturday, September 9, 2017 at 11:35:51 AM UTC-4, paul.rich...@gmail.com wrote:

> ..
> I have just applied a patch to GNU Fortran (GCC) 8.0.0 20170909 (experimental) which implements Parameterized Derived Types. ..

@Paul,

Will it possible for you to share your experiences - the issues and challenges - you faced while implementing the PDT feature in GNU Fortran? How difficult was it, especially the length-type parameter? If you can put together a brief report or a summary of some sort that you can place online, it will be of great help to other implementations. It can also be useful with features in future revisions of the Fortran standard.

Thanks,

Damian Rouson

unread,
Sep 10, 2017, 12:04:10 PM9/10/17
to
Many thanks for your tireless efforts on this, Paul. I have a sense of how much thought and preparation went into this over the years. And thanks for the acknowledgement, especially given that your actual effort greatly exceeds the resources available for financial support. You've done a great service to the Fortran community.

Damian

FortranFan

unread,
Sep 11, 2017, 4:54:31 PM9/11/17
to
On Saturday, September 9, 2017 at 11:35:51 AM UTC-4, paul.rich...@gmail.com wrote:

>.. I would greatly appreciate bug reports, preferably to gcc Bugzilla with the title prefaced by "PDT" or directly to me. ..

@Paul,

If you wish I can send you a simple initial case directly but I thought it will be useful for readers to know of this as well: here's a quick test I tried of what I think is a standard-conforming program and which works as I expect with Intel Fortran:

--- begin PDT example ---
program p

use, intrinsic :: iso_fortran_env, only : CK => character_kinds

implicit none

type :: pdt_t(k,l)
integer, kind :: k = CK(1)
integer, len :: l
character(kind=k,len=l) :: s
end type

type(pdt_t(l=12)) :: foo

foo%s = "Hello World!"
print *, "foo%s = ", foo%s
print *, "len(foo%s) = ", len(foo%s), "; expected is foo%l = ", foo%l
print *, "foo%k = ", foo%k

stop

end program
--- end example ---

Upon compilation with GNU Fortran (gfortran) 8.0.0 20170909 (experimental), the output with errors is

p.f90:10:22:
character(kind=k,len=l) :: s
1
Error: Constant expression required at (1)
p.f90:15:8:
foo%s = "Hello World!"
1
Error: 's' at (1) is not a member of the 'pdtpdt_t_1' structure
p.f90:16:29:
print *, "foo%s = ", foo%s, "
1
Error: 's' at (1) is not a member of the 'pdtpdt_t_1' structure
p.f90:17:38:
print *, "len(foo%s) = ", len(foo%s), "; expected is foo%l = ", foo%l
1
Error: 's' at (1) is not a member of the 'pdtpdt_t_1' structure

The code compiles with no errors or warnings with Intel Fortran and upon execution, the output is as I expect:

foo%s = Hello World!
len(foo%s) = 12 ; expected is foo%l = 12
foo%k = 1

FortranFan

unread,
Sep 11, 2017, 5:12:21 PM9/11/17
to
On Monday, September 11, 2017 at 4:54:31 PM UTC-4, FortranFan wrote:

> .. here's a quick test I tried ..
> Upon compilation with GNU Fortran (gfortran) 8.0.0 20170909 (experimental), the output with errors ..

@Paul,

By the way, as you probably have realized, the following variation with length-type parameter only works fine:

--- begin example ---
program p

use, intrinsic :: iso_fortran_env, only : compiler_version

implicit none

type :: pdt_t(l)
integer, len :: l
character(len=l) :: s
end type

type(pdt_t(l=12)) :: foo

print *, "Compiler Version: ", compiler_version()

foo%s = "Hello World!"
print *, "foo%s = ", foo%s
print *, "len(foo%s) = ", len(foo%s), "; expected is foo%l = ", foo%l

stop

end program p
--- end example ---

Upon execution,

Compiler Version: GCC version 8.0.0 20170910 (experimental)

paul.rich...@gmail.com

unread,
Sep 12, 2017, 3:21:22 PM9/12/17
to
Hi,

Thanks for this - it looks as if I have not implemented the insertion of the KIND expression for characters. I'll take a look later on.

Cheers

Paul

paul.rich...@gmail.com

unread,
Sep 13, 2017, 2:04:28 PM9/13/17
to
Since you provided me with a rather useful testcase later in this thread, which is now fixed and 8.0.0 update this evening, I would be more than happy to oblige :-)

The basic process was one of on-and-off contemplation of how to do this over a period of nearly five years, followed by 6 weeks of coding and testing, which was interspersed with daytime work and eclipse chasing.

It was obvious that instances of the PDTs corresponding to kind parameters would have to be emitted. I looked at all sorts of possibilities to do this using macros or simply producing all the valid combinations straight off.

The light bulb moment came when I realised that all the mechanics to do the job were already present in the gfortran frontend. The treatment of the decl_param_name_list was so similar to that of formal arguments that this was a no-brainer. A namespace, attached to derived types, had already been introduced years ago; partly to take typebound procedures but also with PDT parameters in mind. Symbols, corresponding to each of the type parameters, are put in this namespace.

The next step was the recognition that the type_param_spec_list is sufficiently similar to actual arguments that the associated code was easily modified to accept them. The parameterized expressions associated with each of the components are then walked and the parameter symbols substituted for by the corresponding expressions in the type_param_spec_list.

Finally, LEN parameters were dispatched using the machinery for allocatable derived type components. This turned out to be very straight forward. In fact, looking at it now, it might be a future subject of simplification since, I think, I have repeated some of the parameter substitution unnecessarily.

The principal difficulty that I had, apart from waiting for inspiration, was gleaning from the standard the constraints on the use of the type parameters; most especially deferred and assumed parameters. In fact, there are some corners where I do not think that I have them right even now.

Conclusions:
(i) 5 years of wandering round in circles, 24 hours of inspiration and 6 weeks of perspiration.
(ii) For future new features, if they are this complication, it would be helpful to gather all the relevant changes to the standard, including constraints in one place. For PDTs they are scattered all over the place. John Reid's notes are helpful but not complete enough for this purpose.

Regards

Paul

Damian Rouson

unread,
Sep 13, 2017, 4:52:13 PM9/13/17
to
On Wednesday, September 13, 2017 at 11:04:28 AM UTC-7, paul.rich...@gmail.com wrote:
> Conclusions:
> (i) 5 years of wandering round in circles, 24 hours of inspiration and 6 weeks of perspiration.

Wow. What an incredible journey and a Herculean task.

Damian

FortranFan

unread,
Sep 14, 2017, 2:05:58 PM9/14/17
to
On Wednesday, September 13, 2017 at 2:04:28 PM UTC-4, paul.rich...@gmail.com wrote:

> ..
> Conclusions:
> (i) 5 years of wandering round in circles, 24 hours of inspiration and 6 weeks of perspiration.
> (ii) For future new features, if they are this complication, it would be helpful to gather all the relevant changes to the standard, ..

@Paul,

Thank you very much for your feedback on this, great summary and very valuable.

Re: "i) 5 years of wandering round in circles, 24 hours of inspiration and 6 weeks of perspiration"

- I wonder what the Fortran community kinds about this level of effort. I personally find parameterized derived types to be a valuable addition to the standard: I believe they can serve as part of the broad foundation on which the language can provide improved support for generics, at least toward scientific/technical computing needs. Also, with robust and reliable implementations of PDTs in compilers, I feel one can create more 'convenient' code designs of simulation programs and compute libraries toward, what I call, N-body problems i.e., the computations involved largely make use of data objects whose sizes are some functions of [N], a set of problem sizes ascertained during the initial stages (or the very beginning) of a simulation/calculation, a simple example being a solver class for the solution to N equations. All in all, I will say the value of PDTs in the language far exceeds the level of effort required for GNU Fortran, but that's my opinion only. What do readers think? Can Fortran bring in new features, whatever they be, if the effort was similar to that of PDT implementation in GNU Fortran? I earnestly hope the answer will remain yes.

Re: "ii) For future new features, if they are this complicat(ed), it would be helpful to gather all the relevant changes to the standard, including constraints in one place".

- yes it sounds like a good suggestion. Actually it will be most helpful if the "What's new in Fortran XXXX' document by WG5 following a new revision were to be appreciably more detailed with information on why the features were added, what are the envisioned use cases, detailed code examples that can serve as a necessary (if not sufficient) test suite for all compiler implementations, all this in addition to a compilation of the changes to the standard brought on by the feature. But given the supposedly limited resources, all this appears impossible to achieve.

FortranFan

unread,
Oct 27, 2017, 11:00:03 AM10/27/17
to
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, which is now fixed and 8.0.0 update this evening ..

@Paul,

Thanks again for your follow-up earlier. Here's another case involving parameterized derived types that gfortran fails to compile. If you're interested in following up, you can check the code against the standard; I believe it's conforming and gfortran is wrong to issue the error.

--- begin case ---
module m
type :: t(k)
integer, kind :: k = 1
contains
procedure, pass(this) :: p1
procedure, pass(this) :: p2
generic :: p => p1, p2
end type
contains
subroutine p1( this )
class(t(k=1)), intent(inout) :: this
end subroutine
subroutine p2( this )
class(t(k=2)), intent(inout) :: this
end subroutine
end module
--- end case ---

Compilation output with gfortran, the output is

--- begin output ---
generic :: p => p1, p2
1
Error: 'p1' and 'p2' for GENERIC 'p' at (1) are ambiguous
C:\dev\Fortran\temp\sor\m.f90:5:15:
procedure, pass(this) :: p1
1
Error: Argument 'this' of 'p1' with PASS(this) at (1) must be of the derived-type 't'
C:\dev\Fortran\temp\sor\m.f90:6:15:
procedure, pass(this) :: p2
1
Error: Argument 'this' of 'p2' with PASS(this) at (1) must be of the derived-type 't'
Process terminated with status 1 (0 minute(s), 0 second(s))
3 error(s), 0 warning(s) (0 minute(s), 0 second(s))
--- end output ---

paul.rich...@gmail.com

unread,
Oct 27, 2017, 1:57:35 PM10/27/17
to
Thanks for the report. This is now bug #82753.

Paul

FortranFan

unread,
Oct 31, 2017, 4:23:43 PM10/31/17
to
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.

FortranFan

unread,
Oct 31, 2017, 5:30:51 PM10/31/17
to
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 ..


And a couple more in case they catch your interest:

--- begin case 1 ---
type :: t(k)
integer, kind :: k
end type

type(t(k=1)), allocatable :: foo

foo = t(k=1)()

end
--- end case 1 ---

gfortran.exe -c p.f90 -o p.o
foo = t(k=1)()
1
Error: Invalid character in name at (1)


--- begin case 2 ---
type :: t(ell)
integer, len :: ell
end type

type(t(ell=:)), allocatable :: foo

foo = t(ell=2)()

end
--- end case 2 ---

gfortran.exe -c p.f90 -o p.o
p.f90:7:16:
foo = t(ell=2)()
1
Error: Invalid character in name at (1)

Per my read of the standard, both the above cases are standard-conforming and compile ok with Intel Fortran.

FortranFan

unread,
Oct 31, 2017, 11:41:42 PM10/31/17
to
On Tuesday, October 31, 2017 at 5:30:51 PM UTC-4, 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 ..
>
>
> And a couple more in case they catch your interest:
> ..

And another one to try once the earlier cases are resolved:

--- begin case ---
type :: t(ell)
integer, len :: ell
end type

type :: u
type(t(ell=:)), allocatable :: x
end type

type(t(ell=:)), allocatable :: foo
type(u) :: bar

allocate( t(ell=1) :: foo )

bar = u( x=foo )

end
--- end case ---

gfortran.exe -c p.f90 -o p.o
p.f90:14:14:
bar = u( x=foo )
1
Error: Can't convert TYPE(Pdtt) to TYPE(t) at (1)

paul.rich...@gmail.com

unread,
Nov 5, 2017, 8:08:10 AM11/5/17
to
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.

I will post it on Bugzilla.

Thanks

Paul

paul.rich...@gmail.com

unread,
Nov 5, 2017, 8:21:41 AM11/5/17
to
This is Bug #82842.

I will be having a blitz on PDT bugs the week after next. This one will certainly be squashed.

Thanks

Paul

paul.rich...@gmail.com

unread,
Nov 5, 2017, 8:36:31 AM11/5/17
to
This is Bug #82843.

Thanks

Paul

FortranFan

unread,
Nov 18, 2017, 11:43:44 PM11/18/17
to
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 ..


@Paul,

Fyi - in the other on the ICE with allocatable character type, I just posted a long outstanding issue with gfortran:
https://groups.google.com/d/msg/comp.lang.fortran/Lg8tBwlkS6A/XsR5sxVmAwAJ

And now here's another problem with gfortran, this time with parameterized derived types and one that also involves a structure constructor:

--- begin case ---
type :: t(ell)
integer, kind :: ell
character(len=ell) :: s
end type t

type(t(ell=42)), parameter :: foo = t(ell=42)( s="a" )

print *, "length of foo%s = ", len(foo%s), ", expected length is foll%ell: ", foo%ell

end
--- end case ---

Compilation output with gfortran:

--- begin output ---
gfortran.exe -c p.f90 -o p.o
p.f90:6:38:
type(t(ell=42)), parameter :: foo = t(ell=42)( s="a" )
1
Error: No initializer for component 's' given in the structure constructor at (1)
p.f90:8:42:
print *, "length of foo%s = ", len(foo%s), ", expected length is foll%ell: ", foo%ell
1
Error: Symbol 'foo' at (1) has no IMPLICIT type

You will find this code compiles just fine with Intel Fortran and the output is:

length of foo%s = 42 , expected length is foll%ell: 42


Cheers,

FortranFan

unread,
Nov 18, 2017, 11:46:37 PM11/18/17
to
On Saturday, November 18, 2017 at 11:43:44 PM UTC-5, FortranFan wrote:

> ..
> And now here's another problem with gfortran, this time with parameterized derived types and one that also involves a structure constructor: ..


And a variant:

type :: t(ell)
integer, kind :: ell
character(len=ell) :: s
end type t

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

foo = t(ell=42)( s="a" )
print *, "length of foo%s = ", len(foo%s), ", expected length is foll%ell: ", foo%ell

end

gfortran.exe -c p.f90 -o p.o
p.f90:8:16:
foo = t(ell=42)( s="a" )
1

FortranFan

unread,
Dec 2, 2017, 9:53:19 AM12/2/17
to
On Sunday, November 5, 2017 at 8:21:41 AM UTC-5, paul.rich...@gmail.com wrote:

> ..
>
> I will be having a blitz on PDT bugs the week after next. ..


@Paul,

If you or other GNU volunteers haven't given up on PDTs in gfortran yet, here's another issue to consider (and note I still have more gfortran PDT bug cases for you!!):

--- begin code ---
use, intrinsic :: iso_fortran_env, only : I8 => int64
type :: t(ell)
integer(kind=I8), len :: ell
end type
end
--- end code ---

Compilation response:
gfortran.exe -c -Wall p.f90
p.f90:3:30:
integer(kind=I8), len :: ell
1
Error: Component with LEN attribute at (1) must be default integer kind (4)

You will notice in section 4.5.2 Derived-type parameters in WORKING DRAFT
J3/04-007 May 10, 2004 toward Fortran 2003 in lines 12 and 13 say, "Each type parameter is itself of type integer. If its kind selector is omitted, the kind type parameter is default integer." And the same concept is included in the Fortran 2008 revision and the latest committee draft on Fortran 2018.

As far as I can tell, there is no constraint in any revision of the standard the length-type parameter be of default integer kind.

Thanks,

paul.rich...@gmail.com

unread,
Dec 2, 2017, 2:27:49 PM12/2/17
to
Hi FortranFan,

You might want to update your 8.0.0 - I did a retreat in a cottage in Cornwall last week and fixed a substantial number of PDT bugs. I have to confess that that the above was not among them :-( It is trivially fixed though.

In addition to those that I have fixed, you might want to take a look at the PDT meta-bug PR82173 before unleashing those that you have to hand.

PR82649 is the most pressing of the bugs since it will require a partial rewrite of the implementation in order to introduce PDT descriptors. I have a plan.....

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

I think that all these issues will be sorted out by the time 8.1.0 is released. Thanks for all your help. Also, I should thank Reinhold Bader and Gerhard Steinmetz for all of their testing to destruction of the current PDT implementation.

Regards

Paul


FortranFan

unread,
Dec 30, 2017, 11:10:14 PM12/30/17
to
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)

paul.rich...@gmail.com

unread,
Jan 1, 2018, 1:07:41 PM1/1/18
to
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

Amir Shahmoradi

unread,
Mar 13, 2022, 9:30:15 PM3/13/22
to
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.

Robin Vowels

unread,
Mar 13, 2022, 10:55:32 PM3/13/22
to
.
Try using PL/I.
chr = 'x'; is sufficient.

Paul Richard Thomas

unread,
Dec 15, 2022, 11:09:22 AM12/15/22
to
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

FortranFan

unread,
Dec 15, 2022, 12:07:57 PM12/15/22
to
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.

Amir Shahmoradi

unread,
Dec 20, 2022, 3:01:56 PM12/20/22
to
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

Paul Richard Thomas

unread,
Jan 8, 2023, 1:03:32 PM1/8/23
to
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

Amir Shahmoradi

unread,
Feb 11, 2023, 4:50:06 PM2/11/23
to
Thank you, Paul, for a detailed history of gfortran (that is hardly found anywhere).
My knowledge of GFortran development and its developers is extremely limited.
I know gfortran's development and enhancements are a feat.
Every time I use gfortran, I wonder how a diverse team of volunteers could create such a magnificent compiler on par with commercial products.
Is there the best way to reach out to Jerry Delisle? I could not find his contact info readily on the web.
It appears his approval and direct involvement are required to join https://gfortran.cloud.mattermost.com/
Thank you again,
Amir

Thomas Koenig

unread,
Feb 11, 2023, 4:59:39 PM2/11/23
to
Amir Shahmoradi <a.shah...@gmail.com> schrieb:

> Is there the best way to reach out to Jerry Delisle? I could not find his contact info readily on the web.
> It appears his approval and direct involvement are required to join https://gfortran.cloud.mattermost.com/

That's been taken care of. Please check your e-mail :-)
0 new messages