On Sep 18, 4:13 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:

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
of them will start writing patches themselves).

 * * *

To get involved:

a) Very important is that bugs are reported. If you know a code which
is standard Fortran 95 and it does not work - report it; if possible
try to reduce the source code to the smallest possible which still
reproduces the problem (for proprietary code you need to do so). Same
for all internal compiler errors. Bug reports and feature requests for
Fortran 2003, (common) vendor extensions, better diagnostics etc. are
also welcome but have (naturally) a lower priority [for instance we
already know that CLASS is missing and we plan to add it in 4.5, but
better a bug report/feature request more than one too little].

Even though gfortran has a rather large test suite (94192 lines) and
it is regularly checked against some big real-world codes, benchmark
codes (CPU Spec, Polyhedron) and Fortran test suites, there are and
will be always old and new bugs (regressions), including performance
regressions. Thus doing regular tests with your most favoured codes or
the most wicked corner cases you can can up with are helpful.

Note 1: Not all bugs reported to c.l.f are found and entered in
Bugzilla; it would be nice if users reading c.l.f could also check
whether a bug report exists. If you don't like Bugzilla or are unsure,
whether to fill a bug, you can also write to the fortran insert at
sign gcc.gnu.org mailing list.

Note 2: It makes sense to use the latest developer release (currently
4.4, which is in the bug fixing stage (Stage 3) or the latest released
version (currently 4.3.x). Regressions and important bugs (with fixed
by simple patches) are fixed in 4.3.x and in 4.4, all other bugs will
only be fixed in 4.4. Version 4.2 or older are effectively not
maintained.

Especially if you have access to a non-default system, testing there
(and debugging failures) is especially appreciated as most of the
developers are only using x86 and x86-64 Linux systems, though we have
some regular MacOS PowerPC and Windows users and the test suite is run
on all kind of systems. (However, we lack developers with Windows
expertise, which is an important platform for gfortran in terms of
usage and a bit neglected.)

b) The documentation (http://gcc.gnu.org/onlinedocs/gfortran/ or
http://gcc.gnu.org/onlinedocs/gfortran.pdf ) is in a quite good shape,
but improvements are always possible. If you find an error, fill a bug
report or better create a patch. But also enhancement patches are
highly welcome.

c) If you want to start programming the compiler (and have some [more
or less basic] C knowledge): I think one can find some smaller
projects as starting point, especially accepts-invalid and diagnostic
bugs are usually not too difficult. Compared with the middle-end
compiler work, programming the front end is usually not to difficult
if one has found the way through the files. One essentially programs
like normal; only in the later parts of the compilation process when
the structure for the middle end is generated, it gets a bit more
complicated.

d) If you are really eager or you find a student who is, one can
easily find bigger projects, which might also be funded by e.g. Google
summer of code. (We had two students this year.) Though starting with
(c) makes sense.

Tobias