Patch: f2c.h Question: objc backend

Patch: f2c.h Question: objc backend

[Christopher Seawood]

In the stock 1.0.1 release, f2c.h gets installed in /usr/local/include
regardless of which prefix you specify.  This patch should fix the
problem.

Also, I was sent a patch a while back that fixed the objc backend to
properly handle thread support under glibc.  I was under the impression
that it was in the current snapshot at the time (971215, I think).  Was
there any reason this patch was not included in the 1.0.1 release?

Regards
Christopher
---
Christopher Seawood             * Software Engineer/System Admin
cls@seawood.org                 * http://www.seawood.org

Re: Patch: f2c.h Question: objc backend

[Dave Love]

>>>>> "Christopher" == Christopher Seawood <cls@seawood.org> writes:

 Christopher> In the stock 1.0.1 release, f2c.h gets installed in
 Christopher> /usr/local/include regardless of which prefix you
 Christopher> specify.  This patch should fix the problem.

Exactly why is it a problem?  What does your include search order come
out as?  I'm not sure the current install rule is correct for a
cross-compiler, but the whole g77 build process seems to be in
question in that case.

Re: Patch: f2c.h Question: objc backend

[Dave Love]

>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 Alexandre> I believe this is unnecessary, since, if people compile C
 Alexandre> files (translated from Fortran by f2c) with gcc, it will
 Alexandre> find f2c.h anyway, and it will link against g77's
 Alexandre> libf2c.a.  Is my reasoning wrong?

No, you're right, there will always be _an_ f2c.h found; the question
is whether it's consistent with (a) the libf2c.a that gets linked (b)
been compiled into g77 regarding type sizes.

 Alexandre> Is there any reason to make f2c available?  

It's particularly useful as an interface generator if you're mixing
Fortran and C or something else via a SWIG-like scheme.  [`f2c -P'
gives you C prototypes for the fortran routines corresponding to the
g77 default code generation.]  Presumably G77 could do this, but it
doesn't currently.  It may end up translating more for the g77 runtime
at some stage, but that's not necessarily a reason for distributing it
with g77, and I suspect the things it does that g77 doesn't aren't now
compelling.

Re: Patch: f2c.h Question: objc backend

[Dave Love]

>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

 Craig> This allows g77 to configure and build more automatically than
 Craig> the f2c version of libf2c would by itself (though, perhaps
 Craig> official f2c+libf2c has improved since this was last known to
 Craig> be a problem a couple of years ago).

It's unchanged in that respect and the maintainer was unenthusiastic
about autoconfism.

 Craig>   1.  We could bring all of f2c into the gcc/g77 product
 Craig>       packaging.  It wouldn't take much additional space, but
 Craig>       could take a fair amount of work to get all the
 Craig>       configuration, build, and porting issues resolved enough
 Craig>       to make it worthwhile.

FWIW that's all been done but long enough ago that bitrot will have
set in.  Also it uses automake, which ISTR is verboten in gcc.  (It
was requested for a GNU distribution of f2c but I never wrote the
required Texinfo doc.)  [BTW, f2c is particularly useful for
generating (currently, and with the default options) g77-compatible C
prototypes for Fortran routines.]

Sorry to confuse matters with a misapprehension about why the messing
about is being done as it is.  There definitely are problems with
people mixing G77 code and C being screwed by f2c stuff, though.

Re: Patch: f2c.h Question: objc backend

[Alexandre Oliva]

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?

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

>   2.  We could start to drop any semblance of f2c compatibility from
>       g77

Could there be any performance gain with that?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Patch: f2c.h Question: objc backend

[Craig Burley]

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

Re: Patch: f2c.h Question: objc backend

[Craig Burley]

Here's what I think is the "complete story" on g77's treatment of
`f2c.h'.

g77 relies on the f2c run-time library, named libf2c.  That means
it generates object-compatible calls to that library.

So, with little additional pain, g77 is able to offer object
compatibility with f2c.  [FYI: f2c converts Fortran code to
C code, which the user in turn compiles with a C compiler such
as gcc.]

That is, users can mix g77-compiled and f2c-compiled code in a
single program.  Not only can each kind of object call on the
same library in a "mixy" way -- e.g. g77 code can OPEN a file
on unit 10, then f2c code can WRITE to unit 10, and it all works --
but each kind of object can call on the other (which makes the
former practical).

For reasons involving portability and simplicity, plus being
still fairly primitive, `libf2c.a' is built using some fairly
"brittle" assumptions about data types that affect how
callers pass arguments to `libf2c.a' routines.

These assumptions are encoded in a file named `f2c.h'.

This file is #include'd by `libf2c.a' code, and also is #include'd
by f2c-produced code when it is compiled by the user's C compiler
(which should be the same, or object-compatible with, the one
he used to build `libf2c.a' itself).

Absent g77, f2c installers are encouraged to tailor `f2c.h' to their
system by editing it prior to building `libf2c.a', then making
that edited copy available as the version for all f2c users
who will link to that particular library.

So, a typical f2c installation has a version of `f2c.h' installed
wherever local `.h' files live such that they'll be (automatically?)
picked up when compiling C code produced by f2c.  This version might
or might not have been hand-edited by the f2c installer (probably
not if the system is SunOS, IIRC).

This means that, for most systems, /usr/local/include/ is the
place where `f2c.h' is installed.

Now, g77 enters the picture, and certain things happen.

g77 generates its own version of `f2c.h' during its configuration
(and build?) procedure from a file named `f2c.h.in'.  This allows
g77 to configure and build more automatically than the f2c version
of libf2c would by itself (though, perhaps official f2c+libf2c
has improved since this was last known to be a problem a couple of
years ago).

The g77-generated version of `f2c.h' is, in effect, *already* a
"hand-edited" version in the narrow libf2c sense.

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.

Little of the above *isn't* some kind of kludge, so there's
little of it that can't be reworked, as long as the rework
is done with some overall understanding of the situation, what
is being achieved, and so on.

For example, installing `f2c.h' in some other directory instead
might or might not be a good idea.  It depends on whether f2c
users are likely to pick up that version when linking to the
corresponding `libf2c.a'.

The problem is essentially that g77 is trying, bless its heart,
to get along with the gcc configuration and build environment,
and for most users it succeeds very well.

But it also tries to "eject matter" that will coexist with an
independently provided and separately built and installed product,
f2c, which has pretty much no similarity to gcc's build
environment.

There's a variety of "futures" issues that perhaps suggest various
ways to resolve this situation:

  1.  We could bring all of f2c into the gcc/g77 product packaging.
      It wouldn't take much additional space, but could take a fair
      amount of work to get all the configuration, build, and porting
      issues resolved enough to make it worthwhile.

  2.  We could start to drop any semblance of f2c compatibility from
      g77, leaving it to "knowledgable" users to do the f2c-related
      installation by hand.  The continued use of `libf2c.a' would thus
      be essentially "hidden" from the user base by not installing
      `libf2c.a' anywhere other than in the version-specific library
      directory.

  3.  We could start writing libg77.a, the name we've unofficially
      given the long-term replacement for `libf2c.a' we've been wanting
      to do for years.  libg77.a would *not* offer any compatibility
      with `libf2c.a'.  Whether g77 offered a "compatibility flag" to
      produce code compatible with `libf2c.a' is undecided, but the
      "hook" is there for users who want such compatibility.  (I.e.
      they already have a compiler option they can use, which we can
      start handling by producing a diagnostic when and if necessary.)

Items 2 and 3 are fairly compatible, i.e. we could do 2 now and
3 later.

Doing item 1 might be more helpful to current g77 users, but I'm
not sure how much harder it might make a transition over to 3
(perhaps via 2) in the future.

In any case, we *know* we want to do 3, it's just a matter of timing,
and, probably, funding.  We need a multi-libbed g77 library, one
that handles exceptions, threads, more features, higher performance,
the whole kit and kaboodle.

        tq vm, (burley)

      

Re: Patch: f2c.h Question: objc backend

[Dave Love]

>>>>> "Trent" == Trent Jarvi <chaos@jarvi.ezlink.com> writes:

 Trent> I noticed when porting the egcs rpm package to the alpha
 Trent> machine that f2c.h was left out.  

It should not be left out of gcc-lib/mumble/mumble/include.

 Trent> When I mentioned to people that /usr/local/include/f2c.h was
 Trent> left out I was informed that egcs was wrong.  nothing should
 Trent> go into /usr/local with prefix=/usr.

It's conditionally installed in $(includedir) IIRC, or at least it's
supposed to be.  This is surely discussed in the g77 doc.

 Trent> Christopher took the initiative to fix it.  If its the wrong
 Trent> fix we are interested in hearing so.  I can imagine NFS setups
 Trent> that the original would not be well suited for.  The reason
 Trent> f2c.h is being picked on is it is the only file in the egcs
 Trent> package to go into /usr/local with prefix=/usr

The point is that we want to avoid losing on an incompatible f2c.h
that's already installed and picked up from $(includedir), which is
searched early.  I think at one time the configure/instal procedure
tried to be clever and DTRT according to what was already installed.
This is only relevant if one compiles f2c-generated or f2c-compatible
C code subsequently for linking with g77 output.

I reckon an rpm should not install /usr/local/include/f2c.h but should
generate a conflict with one that's already there.  Or something.
(I'm not an rpm expert.)

Re: Patch: f2c.h Question: objc backend

[Trent Jarvi]

I noticed when porting the egcs rpm package to the alpha machine that f2c.h was
left out.  When I mentioned to people that /usr/local/include/f2c.h was left
out I was informed that egcs was wrong.  nothing should go into /usr/local with
prefix=/usr.

Christopher took the initiative to fix it.  If its the wrong fix we are interested 
in hearing so.  I can imagine NFS setups that the original would not be well suited
for.  The reason f2c.h is being picked on is it is the only file in the egcs
package to go into /usr/local with prefix=/usr

Trent Jarvi

----------------------- Mr Love's Message ---------------------
>>>>> "Christopher" == Christopher Seawood <cls@seawood.org> writes:

 Christopher> In the stock 1.0.1 release, f2c.h gets installed in
 Christopher> /usr/local/include regardless of which prefix you
 Christopher> specify.  This patch should fix the problem.

Exactly why is it a problem?  What does your include search order come
out as?  I'm not sure the current install rule is correct for a
cross-compiler, but the whole g77 build process seems to be in
question in that case.