Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Craig Burley]

>I haven't seen any great problems with the libf2c way of doing library calls,
>and I can imagine much worse ways, having in front of me daily the example of
>HPUX.

I'm not quite sure what that refers to.  My problems with the libf2c
interface include things like not returning COMPLEX arguments in an
efficient way, not putting version numbers and other signature info
on procedures (e.g. a prefix like "libf2c_") to avoid clashes across
separately maintained libraries, etc.  The usual stuff people who've
"been there, done that" in the world of library design whine about
when encountering somebody else's library.

>It might be nice to have a way to invoke the gcc macro facility, but it
>would also contribute to non-portability.

What does that mean?  Do you mean you want to call cpplib, the
preprocessor?  I think that can be done, though it's still
experimental.  Not sure what that, or any other interpretation
I can think of, has to do with libf2c.a and f2c.h.

>I can see what to me are
>significant improvements in parts of the library, without intentionally
>departing from the current f2c conventions.  I'm planning to make up a .diff
>file of my versions compared to egcs 1.0.2

Your math work is definitely something I'd like to start putting
into a libg77.a when that gets built.  Actually I'd like to make
g77 follow what I believe is the Sun convention of getting all
the computations to work as precisely as possible across the entire
domain (turns out g77 doesn't do this with complex multiply, for
example), secondarily make them work fast, tertiarially offer
even faster versions for limited domains (at least I'm guessing
Sun offers this in appropriate situations).  I don't expect
much progress on my end in this area until well into next year,
given my current plans, but that's okay since I'm no math/algorithm
expert.

In the meantime I'm very hesitant about making algorithmic
differences in numerical routines between g77's libf2c and
netlib's.  Even if some things got more accurate, that could
be perceived as introducing bugs in some codes that expected
the previous behaviors (this is Fortran, after all ;-).  So
I think introducing a libg77.a along with other code-generation
changes explicitly advertised as "we're going to try very hard
to get everything right, then everything fast, then let you get
limited-domain answers even faster" is the best time to make
algorithmic changes.

        tq vm, (burley)