A patch for g77spec.c

Craig Burley burley@gnu.org
Sun Jun 21 23:38:00 GMT 1998


>  In message < 199806220104.VAA25662@melange.gnu.org >you write:
>  > I'd prefer it if people would respond to bugs by fixing the bugs,
>  > rather than eliminating the functionality that exposes them.
>Err, I thought it did do the right thing.
>
>g77 version egcs-2.91.41 19980619 (gcc2 ss-980502 experimental) (from FSF-g77 version 0.5.23)
>Reading specs from /usr/egcs/lib/gcc-lib/i686-pc-linux-gnulibc1/egcs-2.91.41/specs
>gcc version egcs-2.91.41 19980619 (gcc2 ss-980502 experimental)
>
>But now it doesn't try to run f771 and link non-existant code.

>From the g77 documentation *in egcs*:

@cindex printing version information
@cindex version information, printing
The command @samp{g77 -v} is a quick
way to display lots of version information for the various programs
used to compile a typical preprocessed Fortran source file---this
produces much more output than @samp{gcc -v} currently does.
(If it produces an error message near the end of the output---diagnostics
from the linker, usually @code{ld}---you might
have an out-of-date @code{libf2c} that improperly handles
complex arithmetic.)
In the output of this command, the line beginning @samp{GNU Fortran Front
End} identifies the version number of GNU Fortran; immediately
preceding that line is a line identifying the version of @code{gcc}
with which that version of @code{g77} was built.

Later:

@item
Improve @code{g77} driver and @code{libf2c} so that @samp{g77 -v}
yields version information on the library.

Then:

@item
@samp{g77 -v} returns much more version info, making the submission
of better bug reports easily.

Further:

@item
The type of machine you are using, and the operating system name and
version number.
(Much of this information is printed by @samp{g77 -v}---if you
include that, send along any additional info you have that you
don't see clearly represented in that output.)

In the installation instructions:

@item Step @value{show-version}: @kbd{g77 -v}
If this command prints approximately 25 lines of output,
including the GNU Fortran Front End version number (which
should be the same as the version number for the version
of @code{g77} you just built and installed) and the
version numbers for the three parts of the @code{libf2c}
library (@code{libF77}, @code{libI77}, @code{libU77}), and
those version numbers are all in agreement, then there is
a high likelihood that the installation has been successfully
completed.

Later:

Here are some commands you can try, and output typically
printed by them when they work:

@example
sh# @kbd{cd /usr/src/gcc}
sh# @kbd{./g77 -B./ -v}
g77 version @value{version-g77}
Driving: ./g77 -B./ -v -c -xf77-version /dev/null -xnone
Reading specs from ./specs
gcc version @value{version-gcc}
 cpp -lang-c -v -isystem ./include -undef -D__GNUC__=2 @dots{}
GNU CPP version @value{version-gcc} (Alpha GNU/Linux with ELF)
#include "..." search starts here:
#include <...> search starts here:
 include
 /usr/alpha-linux/include
 /usr/lib/gcc-lib/alpha-linux/@value{version-gcc}/include
 /usr/include
End of search list.
 ./f771 -fnull-version -quiet -dumpbase g77-version.f -version @dots{}
GNU F77 version @value{version-gcc} (alpha-linux) compiled @dots{}
GNU Fortran Front End version @value{version-g77}
 as -nocpp -o /tmp/cca14485.o /tmp/cca14485.s
 ld -m elf64alpha -G 8 -O1 -dynamic-linker /lib/ld-linux.so.2 @dots{}
 /tmp/cca14485
__G77_LIBF77_VERSION__: @value{version-g77}
@@(#)LIBF77 VERSION 19970919
__G77_LIBI77_VERSION__: @value{version-g77}
@@(#) LIBI77 VERSION pjw,dmg-mods 19980405
__G77_LIBU77_VERSION__: @value{version-g77}
@@(#) LIBU77 VERSION 19970919

>  > short: `g77 -v' is supposed to produce *thorough* information
>  > on the version numbers of all the relevant products (the gcc back
>  > end, the g77 front end, the various libf2c sub-libraries, the
>  > preprocessor, and so on), and even provide a simple test that they're
>  > installed correctly.
>I don't see how you're going to get information from the backend,
>libraries, etc etc without running the backend, running collect2
>and other crud.  Trying to run the backend to get version information
>when there's no input files seems rather wrong to me.

Here's some info from the ChangeLog file for g77:

        Restore circa-0.5.22 capabilities of `g77' driver:
        * Make-lang.in (g77spec.o): Depend on f/version.h.
        (g77version.o): New rule to compile g77 version info.
        (g77$(exeext)): Depend on and link in g77version.o.
        * g77spec.c: Rewrite to be more like 0.5.22 version
        of g77.c, making filtering of command line smarter
        so mixed Fortran and C (etc.) can be compiled, verbose
        version info can be obtained, etc.
        * lang-specs.h (f77-version): New "language" to support
        "g77 -v" command under new gcc 2.8 regime.
        * lex.c (ffelex_file_fixed): If -fnull-version, just
        substitute a "source file" that prints out version info.
        * top.c, top.h: Support -fnull-version.

In short, that info *is* obtained, by, as you put it, "running the
backend...and other crud".  Dunno about running collect2 -- because
I don't know whether that's an issue for g77.

>Note that information will still appear if you do something like
>g77 -v foo.f

Yes, but installers shouldn't be required to first write a Fortran
program; and, further, that info won't include the library version
info that `g77 -v' does from an installed g77.

>But there's no good way to get it for
>g77 -v
>
>Unless you want to embed all the version information in the g77
>binary itself.

The approach I took *already* works...aside from some problem
involving invoking cpp, which I'd assume exists for trying some
other compiles (e.g. with gcc) as well.  Maybe `-B./' is required
for all such commands (e.g. `./g77 -B./ -v', which should work
*without* HJ's patches).  Note that that's recommended in one
on the install-instruction snippets.  I'm aware that some of
the automated test stuff uses `<command> -v' and assumes the
version info will simply appear in some magic form it can
digest (I presume this is documented in the gcc docs for front
ends to obey in their drivers?) -- I had to modify the egcs version
of g77spec.c (`g77') to meet these requirements.  But if that
test stuff expects to be able to do this to an uninstalled driver,
perhaps it could use -B?  (We do seem to have *lots* of warts coming
from a test-suite structure that assumes it knows about the internals
of the compilers it is testing, or at least their installation and
user-interface quirks.  I'd like to see these addressed using more
sound techniques than we presently seem to be, but I'm still coming
up to speed on all this.)

>  > (`g77 -v' as I implemented it in egcs/g77 and g77 0.5.23 does *not*
>  > try to link a non-existant program!!  If it does, that's a bug.)
>It certainly did for me.

The only output I recall seeing reported with bugs in `g77 -v'
showed that *cpp* couldn't be invoked.  That's a different bug;
but, of course, once that happens, it's reasonable that further
errors occur downstream.  (And, it might not be a bug; maybe
supplying `-B./' is all that is needed.)

There are probably missing bits in the egcs version of g77's ChangeLog
that would otherwise show how things evolved to their current state --
they're in g77-0.5.23's gcc/f/ChangeLog, though.  Since there've
been problems getting the patches in properly, I've put off reviewing
all the egcs-g77 activity to see what got dropped during the 0.5.23
upgrade until I get a coherent snapshot, since I've made and submitted
so many patches, some of them quite large and complicated.

It doesn't help, though, when other people make patches to g77 without
even reading up the relevant docs, or waiting for me to indicate
whether they're appropriate.  That makes it *much* harder for me to
track g77 activity in egcs.  Not that it's necessarily crucial for me
to be fully aware of what-all people are doing to g77 in egcs -- if I
decide I can't keep up, that's fine, I can cope -- but it'd be
disappointing to see the quality of egcs-g77 decline vis-a-vis official
g77 simply because people submit and apply patches without even checking
to see how the documentation should be modified to stay up-to-date.

There's an important point here: unlike with C, C++, and Objective-C,
the Fortran audience is not primarily composed of hackers.  And,
unlike with Ada, there's no organization that does most of the work
producing release for paying customers.  So for Fortran users, we've
had to make various things involving g77 work *much* easier for the
users and installers to deal with, including submitting bug reports.

And, we've learned the hard way how likely it can be that people
use g77 built from binaries by someone else, with problems cropping
up in areas such as out-of-sync or mis-installed libraries, etc.
The `g77 -v' approach has probably been the single biggest reason
we've saved ourselves lots of time helping users diagnose problems
that turned out to be this sort of thing.

I believe, in every case, I've sent email to gcc2 explaining the need
for more version info, support for --help, etc., and gotten little or
no constructive response.  But that doesn't mean we didn't put the
appropriate facilities in g77 to make things work.

So please don't assume that if g77 does something differently than gcc,
that means g77 is wrong, or that if gcc doesn't provide some nifty
feature, then g77 couldn't possibly provide it either.  We've spent
the past several years providing work-arounds to gcc deficiencies,
often using very tenuous mechanisms (typically those of gcc itself);
the promise of egcs for us has been at least some respect for what
we've done, perhaps even the integration of our needs into the overall
product infrastructure so we don't need to have g77 remain "different".

Personally, I'd like to see *all* egcs/gcc drivers support --help,
--version, and --verbose at least as well as g77 does.  In the
meantime, I'd like to see egcs-g77 do at least as well in these
areas as the gcc-based g77 does.  To that end, it'd help if other
egcs developers would, in the future, take a closer look before
they know how to "fix" g77 in areas like this (user-interface,
documentation, and so on).  Especially since g77, at least, could
probably use lots more such fixing in the future (asking egcs
developers to read the g77 docs will probably cause lots of bugs
in those docs to be found ;-).

        tq vm, (burley)



More information about the Gcc-patches mailing list