GNU Fortran (G77) BOF Results


C -----------------------------------------------------------------------
C                ----- GNU Fortran BOF Results  -----
C -----------------------------------------------------------------------
C
C News:
C

This page is for historical information only. Much has happened since the events described took place.


C -----------------------------------------------------------------------
C
C Overview:
C

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.


C -----------------------------------------------------------------------
C
C Notes:
C

Notes of the Fortran Birds-of-a-Feather session
at LinuxExpo, Raleigh, NC, 22nd of May, 1999.

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 answers to the first question guided most of the discussion:

 #times
mentioned    Item

    6        Full Fortran 90 support
    3        Cray POINTER support
    2        ALLOCATE / DEALLOCATE
    2        Run time array bound checking
    2        Intrinsics in parameter statements
    2        Improved performance for complex code
    2        Improved debugging
    1        Full compatibility with f2c
    1        Support for OpenMP parallellization
    1        Select case for character variables
    1        Generation of thread safe code

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 !

Toon Moene,
with input from Craig Burley.


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) 1999 James Craig Burley
C based on email by Toon Moene
C
C Last modified 2007-06-09
C
C -----------------------------------------------------------------------