by I've gotten email from people asking about the feasibility of using the
new 2.7.0 release of gcc as a base for incorporating g77 (which is
at version 0.5.15 and based on gcc 2.6.3).
The answer is, please don't try this! 2.7.0 makes a bunch of changes
in configuring, building, and even in the back end, that g77 needs to
know about. You'll probably just get real frustrated (or, worse,
get me frustrated by sending me email about all the problems you run
into :-) by trying.
The good news is that g77 0.5.16 is under development, and earlier
versions of it were alpha-tested, one based on gcc 2.6.3, the other
based on an earlier incarnation (snapshot) of gcc 2.7.0. So, much
of the necessary work has already been done.
I'm working on finished 0.5.16 right now. One approach I took to
fixing a bug in 0.5.15 (see the .plan file for a temporary patch
and other info, as usual) worked, but I decided to replace it with
a better approach, which I'm now doing. This is a 0.5.16 intended
to go with gcc 2.6.3. It also should finally make the big improvement
in certain kinds of array accesses many have been waiting for
(at least, according to one alpha tester who has been pushing for
this for a long time, 0.5.16 should generally meet or exceed f2c|gcc
in this area).
What I might do, before alpha-testing 0.5.16 to find obvious problems
(before releasing it to the public), is see whether it's feasible
to have 0.5.16 work on _either_ 2.6.3 or 2.7.0. It seems easier to
make separate g77 versions at this point, say 0.5.16 for 2.6.3 and
0.5.17 as an equivalent for 2.7.0, but it might be easier in the long
run if I can find some way to unify these versions before releasing
anything. There could be some differences that prevent me from doing
this, however, which is why I have to evaluate the feasibility of this.
The stability of 2.7.0 is, of course, not known yet, but apparently
it makes g77 work better (at all, in fact) on RS/6000 machines, so I
don't want to hold up releasing g77 for 2.7.0 simply because its
stability is not yet established. Plus, I happen to think gcc's
overall stability (in this case defined as "lower N such that release
X.Y.N is considered the final, reasonably stable release of X.Y")
has greatly improved of late.
So, please be patient, I do intend to release a version (or versions)
of g77 that fixes the problems in 0.5.15 _and_ that works with gcc
2.7.0, and as soon as reasonably possible.
Then, if people stop reporting bugs, I can start working on 0.6. :-)
tq vm, (burley)
P.S. I decided maybe not everyone knew about the "known problems" with
0.5.15 and their temporary patches, because not everyone knows about
or can track the g77 .plan file. Here is the relevant text:
Bugs pending or being worked on:
Bad code generated for invoking [DOUBLE] COMPLEX FUNCTIONs and
for doing [DOUBLE] COMPLEX divides and other such things when
the target of an assignment of the value of such expressions
overlaps with one or more of the operands to those expressions
-- fixed in 0.5.16 -- TEMPORARY PATCH: Change gcc/f/com.c:9389:
"if ((TREE_CODE (dest_tree) != VAR_DECL) || TREE_ADDRESSABLE
(dest_tree))" to "if (0)"
Crash in code like DIMENSION A(I**J) where J is not a constant (and,
of course, A is a dummy array) -- fixed in 0.5.16 -- TEMPORARY
PATCH: Change gcc/f/com.c:1904: "if (1 || optimize)" to "if (0)",
which will make slower code for integral power expressions but
at least not crash
Crash in expressions like COMPLEX**INTEGER -- fixed in 0.5.16
More crashes after diagnosing errors -- fixed in 0.5.16
Crash without diagnostic for attempt to define a statement function
with a dummy argument specified more than once in list (such
as "J(I,I)=3" -- fixed in 0.5.16