This is the mail archive of the 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 <19990329070025.10185.qmail@deer>you write:
>  > [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.
>Then it seems to me the only sane way to do this is to provide this
>information as a new predefined type in the compiler, similar to what we
>do with size_t, but that is compatible with what libf2c does for each
>We could even call it f2c_unit_t and f2c_len_t.
>If a port doesn't explicitly define them, then we choose reasonable defaults.

Hey, that sounds good.  I think it's the sort of thing I wanted to do
long ago, and rejected, because of the extremely low likelihood of
getting it into the gcc2 back end in a timely way.  (Like a bird out of
its cage for the first time in years, it's hard to remove the
psychological shackles that keep us from considering the Right Way
to fix things, now that we have egcs.  Well, perhaps the stories I've
read of such birds flying and hopping entirely within a volume equal
to the cage, despite no longer being in one, are apocryphal, but you
get the idea.  :)

I *think* the list of such types is the intersection of ones defined
in egcs/libf2c/g2c.hin and in (with appropriate fixes) egcs/gcc/f/com.h
(maybe com.c).

Presumably f771 would get these types from the gcc back end .h files.
Is that how libf2c would get them, as well?  If so, it'd presumably
be via the configuration step, because I don't think we'd want libf2c
code, itself, #include'ing those .h files.

(If libf2c was written in Fortran, we could extend the g77 language
to explicitly provide the relevant types specifically for this purpose.
Then, using g77 to compile the library, the library would just refer
to those types, and get the right results.  With multilibbing, that
would presumably even accommodate a compiler option to change the
underlying types, a la -mabi=64.  libf2c is written in C, but we could
still do this by teaching gcc about f2c-specific types, so the right
info would be used when compiling libf2c, regardless of #include files.)

>  > Let me ask a question though, a conceptual one.
>I'd consider this a complete non-issue.

Okay, I'm fine with that (vis-a-vis egcs anyway).

        tq vm, (burley)

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