Re: Patch: f2c.h Question: objc backend

[Craig Burley <burley@gnu.org>]

>Craig Burley writes:
>
>> So, to make this version of `f2c.h' available to users of f2c
>> on the system, g77 installs it, along with the version of `libf2c.a'
>> it built, in the canonical include and lib directories if `libf2c.a'
>> isn't already there or explicit overriding macros and/or files
>> exist in the build or source directories.
>
>I believe this is unnecessary, since, if people compile C files
>(translated from Fortran by f2c) with gcc, it will find f2c.h anyway,
>and it will link against g77's libf2c.a.  Is my reasoning wrong?

I don't know, but would like it to not be!  Any excuse to get rid
of these kludges.  What would be best is to ensure that someone can
still use some canned "fort77" script that invokes a canonical,
installed gcc and still pick up the "right" `f2c.h' for use with
the `libf2c.a' they're going to link with.  But if the latter
is part of, say, an egcs gcc that isn't the "installed gcc", then
what means "right" anyway?  So maybe we should just drop this
whole business of installing `f2c.h' and `libf2c.a' anyplace
other than the ordinary "stuff for this version of gcc" places.

>>   1.  We could bring all of f2c into the gcc/g77 product packaging.
>
>Is there any reason to make f2c available?  I can't think of any
>reason to use it, since there is g77, which makes such a better job
>about optimizing loops and such, AFAIK.

f2c has a few advantages over g77 still.  Few enough that I think
few people would mind if g77 dropped its remaining kludges trying
to install elegantly vis-a-vis f2c.  And few enough that we could
probably start knocking off the ones that do remain, one by one,
without a lot of effort.  Besides the arry-bounds-checking feature,
I can't think of an f2c advantage offhand, but know there must be
more, and users would tell us if we need that info, especially
once we drop support.

>>   2.  We could start to drop any semblance of f2c compatibility from
>>       g77
>
>Could there be any performance gain with that?

Not with #2 per se, because I really mean, for "semblance",
"appearance".

That is, #2 is kind of like pretending as if f2c never existed,
leaving it to experienced users or small blurbs in the docs
to understand that g77 still is basically compatible with f2c.

It's #3 where we start taking advantage of that separation,
which probably should be done before #3 (though maybe not --
maybe users will want to see immediate performance gains
to justify moving to a new g77 that even *appears* to no
longer offer compatibility).

And, yes, there should be some substantial performance benefits
available once we undertake #3, primarily in the I/O arena
(formatted, unformatted, even internal I/O), but with plenty
of opportunity to improve raw math speed as well.

        tq vm, (burley)