This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: f2c configure fix



  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.

In fact, I don't see why this problem in any different from other ABI issues
that the compiler already has to solve.

  > 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.

  > 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.

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.


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?

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]