The first-ever g77 Birds-of-a-Feather (BOF)
session was held 1999-05-22 at
LinuxExpo
in Room E1 of the Convention Center
in Raleigh, North Carolina, USA.

At this meeting,
Toon presented us with information
on what improvements
people most wanted made to g77,
based on feedback from his
announcement
of the meeting back in March.

What follows is Toon's notes,
which he emailed around 1999-05-27 to relevant mailing lists.
I have taken the liberty of converting his email to HTML, below,
and applying edits I emailed to him too late to make it into
the version he emailed to the lists.

The input to this BoF was the following questionnaire
(with anti-spam-harvesting modifications), sent to:

newsgroup comp.lang.fortran
mailing lists egcs at egcs.cygnus.com
the g77 alpha testers' mailing list
beowulf at beowulf.gsfc.nasa.gov
- A top-3 list of features (from the "Missing Features" chapter, or
based on your own experience) hindering your use of g77 most.
- The reasons for wanting these features, focusing on:
1. Why you can't proceed without them (if that is so).
2. What effort you have to expend to work around them (type of work,
estimate of manmonths involved).
3. Other reasons.
- Why you think you are not the only casualty of this particular missing
feature.
- How much funding you or your organization / company are willing to
provide to people and/or charitable organizations to provide this
feature.

Actually, during the BoF we didn't deal with the "funding" issue,
although some questions from the 15-odd person audience did touch on
that point:
"Why do people write Free Software? Why are you into it?"

The first thing to notice is that in the two months since the
questionnaire went out, already two issues have been dealt with:

Run time array bound checking

Improved performance for complex arithmetic

These will be in the upcoming gcc-2.95 release.

Spectacular is the overwhelming need for Fortran 90; as far as we can
recall, the fact that GNU Fortran didn't support Fortran 90 wasn't that
much of an issue at the time of first release (February '95), but
Fortran 90/95 compilers are abundant these days and most Fortran users
appreciate (at least some) of the new features in these more recent
Standards. Full Fortran 90 support is, however, a daunting task: this
language is far larger than Fortran 77. Jeff Law asked whether it would
be possible to split this "full support" up in manageable chunks. Craig
Burley pointed out that such an "ad-hoc" approach would be possible,
though he himself would rather work on either a fully-funded g95 product
suite, or a totally different (non-Fortran) project, although he didn't
rule out doing volunteer work if the ad-hoc approach would be decided
upon.

On the other hand, a question from the audience indicated that there is
still a need for support of Fortran 66 constructs. We felt that all of
those mentioned were already supported by the -ff66 compiler option,
however.

The features second and third on the list have to do with the need for
run time allocation of arrays, to overcome the limitations of "largest
problem size guaranteed not to exceed" type of programming that
characterizes so many Fortran 77 codes. Craig felt that the second and
third items of the above list are not hard to implement.

On the issue of improved debugging Richard Henderson remarked that he
had tried to implement the generation of full debugging information for
EQUIVALENCE and COMMON, and it did seem to work; this update, however,
is not included in the pre-gcc-2.95 sources, so it might take a while
before it shows up, because this means that it won't be in the gcc-2.95
release.

Full compatibility with f2c is a necessity if we want people to be able
to use g77 as a replacement for f2c. This means support for the
AUTOMATIC attribute and the -r8 compiler flag (see below).

It would be straightforward but tedious (meaning: a lot of work) to have
g77 generate thread-safe code, especially with respect to the run-time
library. Related to this item is support for RECURSIVE procedures and
the OpenMP shared memory parallellization standard
http://www.openmp.org/,
which provides directives ("hidden" in
comments) for specifying which loops are candidates for
parallellization. The compiler doesn't have to check if such a
parallellization would be in error due to data dependencies, which means
it is rather "easy" on the compiler part. However, it is hard to get
this to work transparently on all g77's targets with their various types
of thread support.

However, another issue is hidden behind the list above - several items
on the list cannot be implemented before a thorough rewrite of GNU
Fortran is completed (intrinsics in parameter statements, and a compile
time option (-r8) to "promote" REAL to REAL*8 and COMPLEX to COMPLEX*16
- it is interesting that the last option doesn't appear in the list
above, however, we know many people have asked for this feature in the
past).

So a vote was cast on the usefulness of first rewriting (parts of) GNU
Fortran and thereby allowing more of the items above being implemented,
or first implementing the "easy" bits and then rewriting. The votes
were slightly in favor of the first option: Rewrite first.

It is likely that this rewrite will be completed in time for the release
of gcc-3.0, which should take place sometime in the fall of this year.
The release date for gcc-2.95 is also not exactly known, but will
probably be somewhere in July.

We would like to thank everyone who sent in their "wishlist" and those
present at the BoF for taking part in the discussion !