Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3]

[Craig Burley <burley@gnu.org>]

>AFAIR the front end is somewhat hamstrung (perhaps depending on
>exactly what the issue is) and there have been long-standing problems,
>especially with the debugging info generated leading to gdb crashes
>trying to assumed-size arrays (which used to appear with huge or
>negative dimensions).  There's an essay on this area in f/com.c
>(ffecom_sym_transform_), at least I think it's relevant.

Somewhat, though IIRC most of that is about the difficulties
of handling adjustable arrays.

Although I haven't really looked into this lately, I believe the
problem is that g77 is telling the back end that "REAL A(*)" is
really REAL A(1:2147483647) since, in theory, that's the
*potential* (but rarely the actual) extent of the range of that
(always-final, i.e. "outer") dimension.

g77 could do what gcc does for a dummy argument like "float a[]",
that is, provide no bounds at all, but that wouldn't work for
cases like "REAL A(0:*)" or "REAL A(10:*)", since g77 needs to
tell the back end about a lower bound.  (Alternatively, g77
could do the FFECOM_FASTER_ARRAY_REFS trick just for this case,
i.e. do its own biasing to cope with a non-default lower bound,
but that would mean very different code-generation paths through
g77 and/or the back end for "REAL A(*)" compared to "REAL A(100)",
which is not justified.)

What I believe I *wanted* to do, long ago, is have g77 simply
leave the *upper* bound unspecified, i.e. a NULL_TREE, and
have the back end simply cope.  That would be an explicitly
documented way to say "upper bound not specified, may be as
high as the corresponding actual-argument's upper bound".

But it wasn't then, and might not be now, easy to teach the
back end about this construct.  If it is now, that would be
my suggestion -- it's a trivial change in the g77 front end,
but if someone can implement the back-end changes to cope with
a NULL_TREE in the "upper" part of a build_range_type call.

(Actually, looking at this, there *is* some pertinent commentary
just about the long essay in f/com.c, that suggests changing
g77 to create a NULL_TREE isn't all that's needed -- other
parts of g77, e.g. the part that checks for possible overlapping
arguments to internal run-time procedures, would need to be
sensitized to this possibility.)

One of the problems we've noticed as being likely to occur
once this is resolved is that there's some confusion as to
whether and how the DWARF (2?) debugging format supports this
construct.  Hopefully someone knowledgable about that will
chime in by the time it becomes an issue.

>I think Fortran isn't really usable until this is resolved somehow
>because that construct is very common.

Agreed.  Lots of old code uses this construct (called "assumed
arrays"), plus some new code as well.

        tq vm, (burley)