f2c configure fix

[craig@jcb-sc.com]

[Moved this to the top:]

>Or is the problem here that you need the structures to be link compatible
>with a libf2c that is not compiled as part of the egcs build procedure?

Yup, that's basically it.  When we drop link-compatibility with libf2c
as a requirement for "normal" g77 compiling, we gain a lot of freedom
(at first -- we *do* have to define and stick with a new library
interface at some point, of course).

>  In message < 19990328140300.12571.qmail@deer >you write:
>  > struct {
>  >   f2c_unit unit;
>  >   f2c_len length;
>  >   } f2c_struct;
>  > 
>  > where `f2c_unit' and `f2c_len' are f2c-defined types (not their real names)
>  > ,
>  > one of the main issues is trying to ensure that the f771 compiler
>  > module agrees with the libg2c run-time library regarding the resolved
>  > forms of those types (their sizes, etc.).
>But what I don't see is why the runtime needs to search for a type for
>f2c_unit and f2c_len.
>
>It seems to me you make f2c_len a "size_t" and the problem goes away since
>gcc already knows how to make its internal "size_t" compatible with the
>external world.  Then do something similar for f2c_unit.

That'd be great, if we could do that.  libg77 should surely do stuff
like that, though I hesitate to be too definitive, having not researched
the relevant library issues.  (I used to be a library-design guru,
believe it or not, around 20 years ago, but that was on a single
architecture -- I haven't explored the issues of cross-platform
portability enough to consider myself a guru in this area of GNU.)

>  > That is, when g77 compiles code, f771 has to know what the underlying
>  > types of the members of `f2c_struct' so it can build instances of that
>  > structure, and libg2c has to know the same thing, so it can contain
>  > C code that manipulates such instances.  (There are various objects
>  > like `f2c_struct' in the libg2c interface, including arguments to
>  > functions.)
>Understood.  But I still don't see why this requires all the hackery we're
>doing right now.

There might indeed be no need for it.  In fact, it might be enough to
have each component do the "obvious" thing, and include a start-up
sanity check for type coherence in main() (which currently is in
libf2c/libg2c).

>  > I don't know what other approaches are used.  My current feeling is that,
>  > ideally, if we were architecting this from scratch (`libg77'), we'd
>  > design libg77 to internally use the "maximum efficient size" for the
>  > types -- e.g. 32 bits on x86, 64 bits on Alpha.  Then, we'd provide
>  > one external interface per combination of potentially useful type
>  > (e.g. 32-bit and 64-bit interfaces, maybe 16-bit as well), accordingly
>  > named.  Each external interface would either copy or promote the values,
>  > or truncate (and crash on overflow), as part of performing the internal
>  > implementation.
>I don't see the need for multiple external interfaces -- maybe that's the
>problem.  It seems to me trying to provide multiple external interfaces just
>makes your problem a lot worse than it needs to be.

Well, I'm pretty good at doing that sometimes.  :)

>Let's pretend that we're going to make both f2c_unit and f2c_len a size_t.
>
>The compiler already knows the precise size of a size_t object.  That size
>can (of course) vary from one target to another, but that's OK, the compiler
>always knows what size it should be for a particular target.
>
>Then in libf2c we always define f2c_unit & f2c_len in terms of size_t via
>configury, sed or whatever means we need.  Problem solved.

Indeed, it would seem to be, if we could do that.

Let me ask a question though, a conceptual one.

Suppose a 64-bit machine like Alpha.  Suppose an OS running on it
that supports both 64-bit and 32-bit addressing.  (Maybe Solaris
on UltraSPARC is a better example, but we're just supposing.)

Conceptually, a compiler might be configured for, and might even offer
a compile-time option to choose between, either 32-bit pointers or
64-bit pointers as a model.

It might even be the case that the ABI requires code compiled in
both models to be linkable together into a runnable program.
(I doubt any ABI today does this, but I don't know about SGI
and other such boxes.  And don't think in terms like "that can't
work under UNIX".  Think about an entirely new OS, with all that
might imply.)

In that case, would your statements about the fixedness of `size_t'
still hold, or would we have to go back to multiple external interfaces
to meet the needs of that ABI in egcs?

The reason I ask is, we don't know what the future holds, so it's
wise to consider not making too many assumptions about it, if
there are feasible alternatives.  (Not that I'm proposing any,
other than just doing the boring, hard work of creating multiple
external interfaces -- which I've done, in other areas, in g77,
e.g. intrinsic support for libU77.  It's painful, but worth
doing right as earlier as possible.  I wish I could have done
more stuff like this "right" in g77, though some things would
need to have also been done right in gcc, assembler, .o format,
executable, and operating system to accommodate that.)

        tq vm, (burley)