Update to 4.2 BSD f77 compiler bug fixes

[Donn Seeley]

First I want to thank the people who responded to my f77 bug reports
with more helpful suggestions, especially Peter Gross, Ralph Campbell
and Bob Corbett.  As a result I have lots of useful information on f77
bugs and I expect to make use of it to fix them later (when I get back
from vacation in January).

Next, a warning about bug (5) on my list, allowing REAL variables to be
put in register.  Bob Corbett said that he could recall a previous
attempt to do this with f77 (& C), and that it resulted in problems
when certain expressions were computed.  Specifically the code
generator occasionally caused part of a DOUBLE PRECISION temporary to
be trashed when evaluating expressions containing both REALs and DOUBLE
PRECISIONs.  I have tried hard to get this to happen in test programs
under my version of the compiler, and I have been unsuccessful.  In
fact the code looks suspiciously like the compiler does a 'global
substitute' of register names for memory references when register REALs
are enabled.  Still, people who implement my suggested fix should
consider themselves warned.  If anyone does try my fix and finds this
bug, please send me mail describing it so I can have a chance to make a
better fix.

Ralph Campbell and Bob Corbett have a better fix for my bug (1) -- I
will post this if I get the chance before I leave on vacation,
otherwise it will wait till January...

It may interest readers on the net to know that there is a reason for
the unpolished state of the f77 compiler in the 4.2 distribution.  I
have been told by people both at and recently away from Berkeley that
there has been some severe instability in the CSRG and related groups
preparing VAX software.  One example of this is that the Berkeley f77
project was (alas) cancelled abruptly in May of this year.  The only
person currently doing any work on f77 at Berkeley is the staff
programmer who oversees the 4bsd-bugs service, who does his repairs in
his spare time.

The cancellation is doubly unfortunate because the project had planned
major optimizer improvements for the compiler but had not completed
implementing them.  Work on a particularly sticky piece of code had
been postponed until this summer; with the cancellation of the project
this work was apparently abandoned.

I was told that the powers that be at Berkeley are not dropping Fortran
for philosophical reasons; they simply have better ways to use their
present staff and students.  So it is possible that new personnel may
eventually be allowed to work on Fortran at Berkeley.  My impression
is, however, that it would be a mistake for you to hold your breath.
There is a possibility that recent changes in the f77 group at BTL (or
whatever that organization is called this week) will bring about a
better compiler from them, so stay tuned.  That's about all the good
news I have.

Trying to forget Fortran until January,

Donn Seeley    UCSD Chemistry Dept. RRCF    ucbvax!sdcsvax!sdchema!donn
32 52' 30"N 117 14' 25"W  (619) 452-4016    sdcsvax!sdchema!donn at noscvax