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

[Craig Burley]

>HPUX Fortran implements libU77 calls by requiring the use of a special pre-
>processor which mangles the names of the +U77 calls implemented in that
>release, plus linking with the +U77 library.  Any functions not implemented in
>that release link with C library functions of the same name, resulting in run-
>time error when a function expecting call by value is called by reference.  So
>I don't see a useful way of including compilers like that in g77's bag of
>compatibility options.

I'm not worrying about that sort of compatibility, at least not for
a very long time!  Sounds like HP took perhaps a kludgey route around
the libU77 problem, which I think we solved best in g77 by "just"
making libU77 procedures into intrinsics, so the compiler knows what
it's doing.  Not that that wasn't a lot of work, but it's made things
as easy as reasonably possible for users -- either they don't have to
edit their code, or they (probably) have to fix it so it is more
portable or continues using the kludgey use-name-as-ordinary-external
approach.

>Nor would I see any reason to use the Sun argument passing convention as it
>was in the old days, where all arguments have to be passed in integer
>registers, even for in-line compiled functions.

No, I'm not thinking about that either.  If we design libg77, we just
don't want to limit ourselves to the calling conventions that libf2c
uses, which are limiting *beyond* whatever ABI is in place.  (That is,
libf2c's interface assumes the basic C ABI, then constrains it further
by, e.g., assuming only some early-generation K&R C conventions can
be safely used.)  libg77 should be more flexible, even to the point
of allowing alternate interfaces for frequently used (at run time)
procedures depending on the optimization needs of the local code, and
use appropriate naming conventions to disambiguate all this, though
that's not required for the first implementations (but the *architecture*
of the library, e.g. the naming scheme, needs to thoughtfully
accommodate it).

>In a message dated 4/19/98 1:40:14 AM Pacific Daylight Time, burley@gnu.org
>writes:
>>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 ;-). 
>
>I find it hard to believe that any g77 code depends on the particular level of
>accuracy resulting from some version of glibc plus the libf2c code.  At the
>very least, such code would not be portable between platforms supporting g77
>nor to compilers other than g77.  Actually, libf2c is nearly as accurate as
>any Fortran in single precision complex, being far better than HPUX or Lahey,
>for example.  

I'm pretty sure people *do*, usually unwittingly, depend to some degree
on *inaccuracy* of their compiler.  At least, based on the bug reports
we get, it seems that way.

However, I think it's reasonable for you to consider submitting
patches to improve numerics to egcs for inclusion in a future release,
so everybody can look at them -- at least, assuming enough relevant
people are testing g77 in the egcs snapshots on their code.

>>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)
>
>Well, I haven't had much access to Suns lately.  I did check at one time to
>see that SGI and HP didn't take any precautions with complex multiply, not
>even promoting single precision complex multiply to use double for
>intermediate operations, which would prevent any damage by under or over-flow
>and assure full accuracy.  I do think that g77 has gone well beyond being a
>compiler primarily oriented toward Sun, or making other brands act like a Sun.
>The day is long gone when Sun made the best Fortran machines.

I get that impression, too, but I'd like g77 to pick and choose the
"best" features among the various implementations and offer them
in a continuing portable compiler.  And maybe Digital Fortran takes
the same approach regarding accuracy, but I know some Sun people have
told me (directly and via c.l.f) that accuracy over complete input
domain is a basic "principle" they stick to, and that seems like a
worthwhile objective for g77 to me.

This seems to be about as much discussion of long-distant futures
issues I should engage in for now, being so busy.  Please don't worry
if I don't respond further, at least right now, but I'm definitely
still interested (and expect others will be too) in further input
on these issues.  That is, I'll read them now, but maybe not respond
to them for some time, so I can keep getting work done.  (I'm getting
*very* used to putting things off.  This August will mark the end of
the fourth year we've lived in our new condo.  I haven't finished
unpacking my stuff yet.  ;-)

I should note that the g77 docs have some relevant background
materials on most of the above issues.

        tq vm, (burley)