g77/gdb problem

craig@jcb-sc.com craig@jcb-sc.com
Sun Sep 5 11:43:00 GMT 1999


>On Tue, Aug 03, 1999 at 08:49:46PM +0200, Toon Moene wrote:
>> Richard Henderson said - during the Fortran Birds of a Feather session
>> at LinuxExpo this May - that he had a series of patches for the Fortran
>> frontend that would enable real debugging info for COMMON blocks. 
>
>It's attached.
>
>> Perhaps he's willing to try them out on the main trunk, so that it might
>> be installed in time for the gcc-2.96 release ...
>
>That's up to Craig, I think.

I've tried out the patch on my private test suite and found several
failures (new ICEs).  I've put four of the six failing cases (one of
the other two likely includes at least one of the other four anyway,
the sixth seems to large to put in when there are enough small cases)
into the testsuite.

Offhand, I think these failures might be due to the unfortunate "timing"
needed to cope with a dummy declaration like REAL A(N) where N is in
COMMON.  In that case, the back end cannot be told about the toplevel
function, because it wants to know all about the arguments.  (Kinda silly;
an example of the C-centric nature of the back end, but perhaps too
thoroughly ensconsed in the code at this point.)

But, the argument is dimensioned by a component of a common area -- more
to the point, a *local* mapping of that common area.  (I.e. there is,
in Fortran, no "toplevel" mapping of a common area that everyone agrees
to -- there's just the rough equivalent of "[extern] char commonarea[SIZE];".
Each toplevel procedure gets to decide whether, say, the third word
in it is an integer named N, a float named V, or whatever.)

If the back end allowed a function to be started, then definitions of
local types and local views of global storage to be *mixed* with those
of dummy args, this wouldn't be a problem.  Maybe that's the best fix
to make in the long run.

In the meantime, while my plans for fixing what rth is trying to fix
here were more comprehensive (he's using the "out of band" method,
where distinct info on a common area is presented to the back end,
whereas I've felt the "right", or safest, way was to change g77 to
use C-like structuring of the common/equivalence areas for both
code generation and debug-info generation), they required a solution
that I think would work fine (in simpler form) here.

Specifically, when the front end is transforming dummies, it should
just skip any "structure-related" work on common areas.  I.e. aside
from doing the "[extern] char commonarea[SIZE];" thing, and transforming
"REAL A(N)" to (roughly, ignore precedence stuff) "float *a[*((int *)
commonarea[12])];", it should not try to use the local view of how
the common area is structured for anything that involves talking to
the back end -- since the back end doesn't yet know about the toplevel
function, and thus doesn't want to know about the way that function
views the common area.

        tq vm, (burley)


More information about the Gcc-bugs mailing list