GNU Fortran (g77) Version 0.5.22 Released

GNU Fortran (g77) Version 0.5.22 Released

[Craig Burley]

This release includes many changes since 0.5.21.  A list is included
below.

The primary focus of this release is to fix bugs in 0.5.21 and add
one or two new features that are considered important to add at this
time.  0.5.22 is intended as a drop-in replacement for 0.5.21.

See the .plan file for g77 < ftp://alpha.gnu.org/g77.plan > for
information on plans for future releases.

    g77-0.5.21-0.5.22.diff.gz -- Patch file to apply to 0.5.21
    g77-0.5.22.tar.gz         -- Complete 0.5.22 distribution

NOTE: The patch file does not include patches to the Info documentation,
which is derived from the texinfo sources in the distribution (and
updated via the patch).  This is to reduce the size of the patch file.
If you don't have makeinfo version 1.68 (or more recent) installed
(distributed as texinfo-3.11.tar.gz), obtain and use the full distribution
instead.  However, it is definitely worthwhile having texinfo installed
and making full use of GNU Info documentation!

Please report any bugs or questions to <fortran@gnu.org>,
after first reviewing the documentation and the .plan file.

(GNU Fortran is a free replacement for the UNIX f77 Fortran compiler,
and is currently in beta testing.  To build it requires the GNU CC
source distribution, Version 2.7.2.3, which you can obtain as
gcc-2.7.2.3.tar.gz from a GNU distribution site.)

        tq vm, (burley)


In 0.5.22:

   * Fix code generation for iterative `DO' loops that have one or more
     references to the iteration variable, or to aliases of it, in
     their control expressions.  For example, `DO 10 J=2,J' now is
     compiled correctly.

   * Fix a code-generation bug that afflicted Intel x86 targets when
     `-O2' was specified compiling, for example, an old version of the
     `DNRM2' routine.

     The x87 coprocessor stack was being mismanaged in cases involving
     assigned `GOTO' and `ASSIGN'.

   * Fix `DTime' intrinsic so as not to truncate results to integer
     values (on some systems).

   * Fix `SIGNAL' intrinsic so it offers portable support for 64-bit
     systems (such as Digital Alphas running GNU/Linux).

   * Fix run-time crash involving `NAMELIST' on 64-bit machines such as
     Alphas.

   * Fix `g77' version of `libf2c' so it no longer produces a spurious
     `I/O recursion' diagnostic at run time when an I/O operation (such
     as `READ *,I') is interrupted in a manner that causes the program
     to be terminated via the `f_exit' routine (such as via `C-c').

   * Fix `g77' crash triggered by `CASE' statement with an omitted
     lower or upper bound.

   * Fix `g77' crash compiling references to `CPU_Time' intrinsic.

   * Fix `g77' crash (or apparently infinite run-time) when compiling
     certain complicated expressions involving `COMPLEX' arithmetic
     (especially multiplication).

   * Fix `g77' crash on statements such as `PRINT *,
     (REAL(Z(I)),I=1,2)', where `Z' is `DOUBLE COMPLEX'.

   * Fix a `g++' crash.

   * Support `FORMAT(I<EXPR>)' when EXPR is a compile-time constant
     `INTEGER' expression.

   * Fix `g77' `-g' option so procedures that use `ENTRY' can be
     stepped through, line by line, in `gdb'.

   * Fix a profiling-related bug in `gcc' back end for Intel x86
     architecture.

   * Allow any `REAL' argument to intrinsics `Second' and `CPU_Time'.

   * Allow any numeric argument to intrinsics `Int2' and `Int8'.

   * Use `tempnam', if available, to open scratch files (as in
     `OPEN(STATUS='SCRATCH')' so that the `TMPDIR' environment variable,
     if present, is used.

   * Rename the `gcc' keyword `restrict' to `__restrict__', to avoid
     rejecting valid, existing, C programs.  Support for `restrict' is
     now more like support for `complex'.

   * Fix `-fpedantic' to not reject procedure invocations such as
     `I=J()' and `CALL FOO()'.

   * Fix `-fugly-comma' to affect invocations of only external
     procedures.  Restore rejection of gratuitous trailing omitted
     arguments to intrinsics, as in `I=MAX(3,4,,)'.

   * Fix compiler so it accepts `-fgnu-intrinsics-*' and
     `-fbadu77-intrinsics-*' options.

   * Improve diagnostic messages from `libf2c' so it is more likely
     that the printing of the active format string is limited to the
     string, with no trailing garbage being printed.

     (Unlike `f2c', `g77' did not append a null byte to its compiled
     form of every format string specified via a `FORMAT' statement.
     However, `f2c' would exhibit the problem anyway for a statement
     like `PRINT '(I)garbage', 1' by printing `(I)garbage' as the
     format string.)

   * Improve compilation of FORMAT expressions so that a null byte is
     appended to the last operand if it is a constant.  This provides a
     cleaner run-time diagnostic as provided by `libf2c' for statements
     like `PRINT '(I1', 42'.

   * Fix various crashes involving code with diagnosed errors.

   * Fix cross-compilation bug when configuring `libf2c'.

   * Improve diagnostics.

   * Improve documentation and indexing.

   * Upgrade to `libf2c' as of 1997-09-23.  This fixes a formatted-I/O
     bug that afflicted 64-bit systems with 32-bit integers (such as
     Digital Alpha running GNU/Linux).

Re: GNU Fortran (g77) Version 0.5.22 Released

[Jeffrey A Law]

  In message < 199803172045.PAA01384@melange.gnu.org >you write:
  > This release includes many changes since 0.5.21.  A list is included
  > below.
  > 
  > The primary focus of this release is to fix bugs in 0.5.21 and add
  > one or two new features that are considered important to add at this
  > time.  0.5.22 is intended as a drop-in replacement for 0.5.21.
  > 
  > See the .plan file for g77 < ftp://alpha.gnu.org/g77.plan > for
  > information on plans for future releases.
  > 
  >     g77-0.5.21-0.5.22.diff.gz -- Patch file to apply to 0.5.21
  >     g77-0.5.22.tar.gz         -- Complete 0.5.22 distribution
An FYI -- I've imported the 0.5.22 sources into egcs.  No significant
merge conflicts.  Any minor merge problems we'll shake out soon
enough :-)

jeff

Re: GNU Fortran (g77) Version 0.5.22 Released

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:

 Jeff> An FYI -- I've imported the 0.5.22 sources into egcs.  No significant
 Jeff> merge conflicts.  Any minor merge problems we'll shake out soon
 Jeff> enough :-)

Could we keep a `vanilla' -- i.e. g77-0.5.22, at this stage -- g77 and
libf2c release branch in the egcs repository, I guess including the
`hot fixes', but probably not alpha test code?  (Or would this not be
a good idea?)  I could maintain it, presumably.

Re: GNU Fortran (g77) Version 0.5.22 Released

[Jeffrey A Law]

  In message < rzqzpifk8la.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:
  > 
  >  Jeff> An FYI -- I've imported the 0.5.22 sources into egcs.  No significan
  > t
  >  Jeff> merge conflicts.  Any minor merge problems we'll shake out soon
  >  Jeff> enough :-)
  > 
  > Could we keep a `vanilla' -- i.e. g77-0.5.22, at this stage -- g77 and
  > libf2c release branch in the egcs repository, I guess including the
  > `hot fixes', but probably not alpha test code?  (Or would this not be
  > a good idea?)  I could maintain it, presumably.
Do you mean on a branch?  Or do you mean in the mainline sources?

Getting it on a branch wouldn't be too hard....  In fact, 90% of
the work is already done :-)

If you mean don't install any more g77 patches, I think that would
be unwise.  After all we're developing the g77 compiler as well
as the other compilers.

jeff

Re: GNU Fortran (g77) Version 0.5.22 Released

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 >> Could we keep a `vanilla' -- i.e. g77-0.5.22, at this stage -- g77 and
 >> libf2c release branch in the egcs repository, I guess including the
 >> `hot fixes', but probably not alpha test code?  (Or would this not be
 >> a good idea?)  I could maintain it, presumably.
 Jeff> Do you mean on a branch?  Or do you mean in the mainline sources?

A branch.

 Jeff> Getting it on a branch wouldn't be too hard....  In fact, 90% of
 Jeff> the work is already done :-)

Sorry, I probably have mis-read the tags (which perhaps aren't the
best named).  It looks as though the barnch is actually there.

 Jeff> If you mean don't install any more g77 patches, I think that would
 Jeff> be unwise.  After all we're developing the g77 compiler as well
 Jeff> as the other compilers.

No, not at all.  I meant by `alpha test' things actively under test on
the g77-alpha list, as opposed to the `hot fixes' advertised in
g77.plan.

Re: GNU Fortran (g77) Version 0.5.22 Released

[Jeffrey A Law]

  In message <rzqsoo1txqb.fsf@djlvig.dl.ac.uk>you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  >> Could we keep a `vanilla' -- i.e. g77-0.5.22, at this stage -- g77 and
  >  >> libf2c release branch in the egcs repository, I guess including the
  >  >> `hot fixes', but probably not alpha test code?  (Or would this not be
  >  >> a good idea?)  I could maintain it, presumably.
  >  Jeff> Do you mean on a branch?  Or do you mean in the mainline sources?
  > 
  > A branch.
OK.  Yes, we can do this.


  >  Jeff> Getting it on a branch wouldn't be too hard....  In fact, 90% of
  >  Jeff> the work is already done :-)
  > 
  > Sorry, I probably have mis-read the tags (which perhaps aren't the
  > best named).  It looks as though the barnch is actually there.
Most of it is there.  The runtime directory wasn't imported under
gcc/f, but instead was imported in the libf2c toplevel dir.

If you want I can import it under gcc/f/runtime, it shouldn't be a
major problem (and it won't show up in the mainline tree).

Yes, the tags for importing and checking out the vendor branches
need some tweaking -- basically I goof'd the first import and
reversed the vendor branch tag and the vendor release tag.  I need
to do some reading to find out the best way to fix that problem.

jeff