dwarf2out.c crash triggered by g77 (was Re: Irix6 failure)

[Craig Burley <burley at gnu dot org>]

>A build worked on Irix6.4 and immediately failed `make check' in
>f/runtime.  I'm passing this on for info as I'm probably not going to
>be able to debug it in a hurry.  (Last time I tried egcs on that
>system it did work, but that might have been a couple of months ago.)

I've looked into this, as best I can anyway, and it looks like
the problem is that a CHARACTER*(*) dummy arg is encoded by g77
in a way the dwarf2 output module doesn't expect.  All the
other debug output modules seem to be able to cope with it;
essentially g77 is putting the actual PARM_DECL that identifies
the "phantom" dummy argument containing the actual length of
the string in the upper-bound slot for the TYPE_DOMAIN field
of the array.

This is a problem with gcc 2.8.1, and, upon inspection of the
relevant code, is likely a problem with egcs 1.0 and 1.1 as well.

I'm not sure which is the best way to fix this.  Obviously just
teaching dwarf2out to handle PARM_DECL in add_bound_info() is
one way.

Another way is to change g77 to pass the tree node through
variable_size() before putting it in the upper-bound slot.

Normally variable_size() is used to ensure that the array's
bounds don't change when the underlying variables (those that
appear in the expression(s) for the bounds) are changed during
execution of the procedure.

However g77 can get away with this case because g77, not the
user code, knows about the underlying variable (it's a "phantom",
or invisible-to-the-user, argument passed by the caller), and
knows it won't change that variable, a la:

void
foo (char *a, int n)
{
  ...;
}

In the above, if the foo routine doesn't change n, and n specifies
the number of characters (size) of the a array, then it doesn't
need to make a copy of n to keep that size the same.

Even if I change g77 to do this, avoiding the problem in dwarf2out,
it still looks like that code will probably not recognize that the
upper bound of the array is an argument to the procedure (or a
saved version thereof) and tell the debugger about it.  But at least
it shouldn't crash.  There are many more g77/gdb problems than
this, and I expect we'll tackle most or all of them at once later
this year, when we can gather all the specs and people together
for a jam session.

If anyone in the gcc2 or egcs has comments, let me know.  I'll
probably try changing g77 shortly, to see if it has any noticable
effect on existing code.

        tq vm, (burley)