> Over the last few years I have developed a 30,000 line Fortran-95
> engineering application using simultaneously several compilers (XLF,
> LF95, G95, and IVF).   During that time I toyed with Gfortran and put
> up with the 2 steps forward, 1 step back of each binary build.
> However, I'm now happy to report my "last" issue with it has been
> resolved and more importantly performance is almost identical to XLF
> and IVF in most cases.  Congratulations to all involved with this
> project!
>
> Al Greynoldswww.ruda.com

>> Over the last few years I have developed a 30,000 line Fortran-95
>> engineering application using simultaneously several compilers (XLF,
>> LF95, G95, and IVF). During that time I toyed with Gfortran and put
>> up with the 2 steps forward, 1 step back of each binary build.

>> However, I'm now happy to report my "last" issue with it has been
>> resolved and more importantly performance is almost identical to XLF
>> and IVF in most cases. Congratulations to all involved with this
>> project!

>

> Al and Damian,
>
> Many thanks for the praise - every little bit helps:-)
>

>>> Over the last few years I have developed a 30,000 line Fortran-95
>>> engineering application using simultaneously several compilers (XLF,
>>> LF95, G95, and IVF).   During that time I toyed with Gfortran and put
>>> up with the 2 steps forward, 1 step back of each binary build.

>
> We are sharply aware of this problem.  It has come about largely
> because of the inadequacy, in the past, of our testsuite.  Not having
> a take-the-standard-and-write-a-testsuite yardstick to go by, ours has
> grown as we have fixed bugs and regressions.  Thus, our random walk
> through bugspace  is, at least Markovian; for the main part they do
> not get repeated.  Also, whilst some of the things that people try to
> do are "ïnteresting", the space in which we can wander seems to be
> bounded too.
>

>>> However, I'm now happy to report my "last" issue with it has been ...

> On 18 sep, 09:56, paul.richard.tho...@gmail.com wrote:

>> One feature of the gfortran maintainers group is that there is a
>> fairly continuous turn-over, with a characteristic time of a few
>> years. Thus, we are always on the lookout for new blood. If anybody
>> out there is interested in joining in, please get in touch.

>
> Perhaps you can describe in some detail how people can help out:
> developing a compiler seems a rather daunting task and if you
> can tell about the less daunting aspects and tasks you may get more
> people involved.

> Hi Arjen,
>
> On Sep 18, 4:13 pm, Arjen Markus wrote:
>

>> On 18 sep, 09:56, paul.richard.tho...@gmail.com wrote:

>>> One feature of the gfortran maintainers group is that there is a
>>> fairly continuous turn-over, with a characteristic time of a few
>>> years. Thus, we are always on the lookout for new blood. If anybody
>>> out there is interested in joining in, please get in touch.

>

>> Perhaps you can describe in some detail how people can help out:
>> developing a compiler seems a rather daunting task and if you
>> can tell about the less daunting aspects and tasks you may get more
>> people involved.

>
> I think the typical way one gets deeply involved with gfortran
> development is as follows:
>
> 1. One starts using it and finds a bug/missing feature, which one ...

> Perhaps you can describe in some detail how people can help out:
> developing a compiler seems a rather daunting task and if you
> can tell about the less daunting aspects and tasks you may get more
> people involved.

> On Sep 18, 4:13 pm, Arjen Markus wrote:
>

>> Perhaps you can describe in some detail how people can help out:
>> developing a compiler seems a rather daunting task and if you
>> can tell about the less daunting aspects and tasks you may get more
>> people involved.

>
> Well, daunting, daunting... Compiler construction as a (black) art is
> overrated ;-)
>
> You have to realize that not a single one of the gfortran developers
> (current and past, including g95) have a computer science background.
> At least, not as far as I know.
>
> All gfortran developers are physicists, engineers, mathematicians,
> etc., in their Real Life, just like most people that follow this
> newsgroup. These developers started as Fortran users, with no more
> knowledge of compiler construction than most people here.
> ...

>
> Since I can't report any new bugs, I'm glad to volunteer to work on
> the things that excite me the most. I would be very excited to see
> the following implemented and will contribute if someone can give me
> specific guidance on where to start with these:
> 1. allocatable scalars
> 2. final procedures

> 3. polymorphic variables
> 4. type guard statements
> These are the most important things I need from gfortran to get it to
> compile a new code I'm working on. Of the compilers I've tried, it
> currently only compiles with IBM XL Fortran.

> Hi Arjen,
>
> I think the typical way one gets deeply involved with gfortran
> development is as follows:
>
> 1. One starts using it and finds a bug/missing feature, which one
> reports
> 2. One starts building gfortran oneself
> 3. One creates a small, simple patch, e.g. for a trivial bug or for
> the documentation
> 4. One gets involved in fixing bugs
> 5. One starts writting bigger patches & reviews other patches
> 6. The steering committee appoints one as maintainer
> (7. All the programs one uses work and one gets other work to do and
> thus one mostly stops gfortran development)
>
> Any help at either stage is welcome (though (7) less so ;-) and there
> are several contributers which restrict themselves to finding bugs,
> triaging bugs and testing patches (though I still have the hope some ...