Now that I've stepped down from my de-facto role as
g77 project leader,
as well as away from ongoing
The GCC Steering Committee should appoint new leadership for
My fondest hope is that this will result in many more volunteers
stepping forward to help maintain and improve
Since each volunteer might have little time and might, for various reasons,
prefer to concentrate on one activity at a time,
I've provided a list of "hats" I've worn over the years,
as well as those worn by other developers and supporters of
below, in the form of simple job descriptions:
g77project leader, to have the final word on most issues vis-a-vis the official
libf2c, integrating them (as appropriate) into
g77-specific prerelease and release issues.
g77available (via forums such as the World Wide Web) seems to have been effective, to the limited extent to which it's been tried.
g77, if not actually go searching for it.
These items are expanded upon below.
If you have comments on this document, email me at g77-next at-sign jcb-sc.com. It's definitely a "living" document!
This person (or group) should undertake the following:
g77be allowed to "wither on the vine" as users choose newer languages, newer compilers, and so on? Should it be maintained to at least continue building, passing the test suite, etc.? Should it be actively developed, or should resources used for that work go into a GNU Fortran 90, 95, or 2000? Update: There now is a GNU Fortran 95 project at http://g95.sourceforge.net/.
g77, ask them to help out. Ditto if they report a bug. Point them to the GCC web site, where it explains how people can help.
g77is in a fairly unique position vis-a-vis mathematics. Unlike C or C++, getting math "right" is crucial to its usefulness. Unlike Java, there's no industry-wide agreement on what constitutes "right". In particular, is
g77first fast, then, with various tweaks (changing user code, having users specify command-line options, etc.), reliable and predictable? Or the other way around? Before Java, the easier choice was the first, since going fast is (generally) more important to C/C++ users than getting consistent results (when it comes to floating-point arithmetic, anyway). Now, with a Java front end being developed, the second choice is becoming supported. Java wants perhaps too much predictability over speed, but if the Fortran crowd keeps up on developments and picks its fights wisely, it could end up with a more-Java-like degree of predictability and consistency combined with Cray-Fortran-like speed. Among the factors to consider in setting this direction is the issue of defaults and how they affect testability. Generally, the more consistent and predictable the behavior of a Fortran compiler, the more existing (legacy and new) code that can be thrown at it for regular testing. That's why I, personally, favor choosing the second option. If, instead, users have to change their code to get
g77to behave as another compiler has (perhaps taking advantage of its native CPU architecture), even if they can just use command-line options to work around the problems, that means less testing overall. And, less testing overall leads to more hard-to-find or last-minute bugs, and these are most likely to be in the "second-class" area. I'd prefer that area to be trying to squeeze the last ounce out of performance, since programmers doing that generally know their stuff and can find bugs quicker, than in trying to get
g77to be as predictable as other compilers.
libI77components to be as close to
libf2cas possible. Also decide whether and how to undertake a
libg77project (a whole new library design, including a new API). There are various snippets and notes about what this might comprise in the docs and elsewhere.
g77, they need to have some clue as to what it's supposed to look like. The Fortran standards are of some use here, but they don't specify anything particularly useful about how floating-point arithmetic should behave, what basic types are supported, how I/O should be implemented across different operating systems, and so on. These include tricky issues. For example, does a
g77user expect a program to read/write the same unformatted data files regardless of the underlying system? That would be more consistent with today's emerging Internet client/server architecture, but maybe it's inappropriate to offer unformatted files for that use, as another user might expect
g77to default to reading/writing them in a fashion compatible with other compilers typically used on that underlying system. (These goals are, simply put, incompatible.)
g77to be the Fortran compiler for every last bit of legacy code out there? Should it be, instead, a great compiler for the GNU Fortran language, a language that is based on a Fortran standard and extended precisely as much as needed to accommodate the overall GNU environment? Or should it be something in between? Right now,
g77is a hodepodge of both, leading to an in-between-ness that is hard to explain or justify without resorting to explaining the history. For example, I wrote the lexer thinking it could perhaps be the last lexer ever needed for Fortran — from legacy to new code. Whereas, by the time I got to the later phases of compilation, I was happy to just get the basics working. Turns out getting the basics working, and doing little more, leads to a more robust product. Some of the hairiest stuff in the front end is due to my trying to accommodate extensions I hadn't heard of yet. Sticking to a simple, clean language allows the compiler to be smaller, the maintainence load to be easier, and generally allows more people to work on it simultaneously (and productively) than otherwise, because there are fewer "global switches" for programmers to constantly track. Then, people with special-needs, legacy code can use converters for the code. Ditto for data files, shell scripts, whatever. Those converters can be shipped with, but not otherwise interfere with,
g77itself. The one-size-fits-all approach has its advantages, though. For one thing, it's easier to know when to say "no" to a request for a new feature or an accommodation of an old coding style. (Specifically, never say "no".)
One or more people should be designated as prepared
to respond to bug reports vis-a-vis
This includes notifying the sender if the bug report is incomplete, cannot be reproduced, or, optionally, if the bug has been fixed.
It also includes forwarding the report to others, who might be able to offer help responding to it, but might not be carefully reading all such reports themselves.
Someone should watch patch submissions for those that
apply, or might imply some needed action regarding,
This person should make some initial assessments regarding
the viability of these patches.
Is a given patch complete?
How might it break things?
Should it be applied to a release branch,
to the trunk,
or to an experimental branch?
libg2c patch to
be applied, partially or fully,
Someone should keep up with changes to Netlib
integrating them (as appropriate) into
This includes serving as the contact between the
g77 project leader
and the Netlib
(currently dmg at-sign bell-labs.com).
Since first publishing this document
I've added some scripts to the `contrib/' subdirectory
in the CVS tree for GCC.
These help download and unpack
as well as convert it back and forth to
Someone should ensure documentation keeps up with bug reports and patches, as well as comments and questions.
For example, when a question is repeatedly asked and answered, that suggests a need to improve the documentation so simple pointers into the docs can be provided.
This person should also be alert to proposals that might affect
the behavior or performance of
and take appropriate action,
such as requesting detailed specifications of the new behaviors,
or that the time and effort needed to update the docs
be taken into account when assessing the overall effort
needed to implement a proposal.
Someone should handle
g77-specific prerelease and release issues.
This requires some close coordination with the release manager
for GCC as each release approaches.
Keeping the `gcc/f/bugs.texi' and `gcc/f/news.texi' files up-to-date has been important to me, so I'd like them to be kept up-to-date. If not, they should be clearly marked as deprecated.
Making information on
(via forums such as the World Wide Web)
seems to have been effective, to the limited extent
to which it's been tried.
g77 web site
has served reasonably well for some of 1999,
but it could be greatly improved upon.
Perhaps one or more volunteers could be found
who could put together a really great web site for
full of links to other sites
(like mine, which I don't mind maintaining for the time being)
that pertain to
g77, Fortran, free (libre) number-crunching software,
and so on.
One or more people should watch Internet forums
for postings of opinions, commentary, alerts, and so on,
that might pertain to
URLs and other references to such items,
deemed pertinent to the
g77 development team,
could be forwarded to the project leader,
to a GCC mailing list,
If there's enough activity in this area,
perhaps the volunteer could put together
a digest of references (ideally with summaries)
on a web site somewhere,
pointed to from the
g77 web site.
It might be helpful to have someone designated to
be alert to opportunities to obtain funding to improve
if not actually go searching for it.
Collecting and summarizing information on
opportunities and needs (or requests) for
could prove very important to the long-term health of
(or whatever "GNU Fortran" means in the future,
such as a
C ----------------------------------------------------------------------- C ----- GNU Fortran (g77) ----- C ----------------------------------------------------------------------- C PROGRAM G77 C COMMON/QUICKY/QNEWS,QWHAT,QWHO,QHOW,QWHERE,QRLEAS,QSTAT,QWANT, 1 QY2K,QALIGN,QFUND,QF2C,QMAIL C REAL BOF C WHAT() = 2. * 3.14 * QWHAT C READ *,STATUS,NEXT CALL GIMME(FUNDS,*999) PRINT *,'Goodies For Contributors!!' GO TO (999),NEXT CONTINUE INQUIRE (UNIT=99,NAME=WANTED) CALL WHO(CRUNCH) 999 STOP 3HWHY END C C ----------------------------------------------------------------------- C C Copyright (C) 2000 James Craig Burley C C Last modified 2007-07-16 C C -----------------------------------------------------------------------