From mboxrd@z Thu Jan 1 00:00:00 1970 From: Craig Burley To: egcs@cygnus.com Subject: Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] Date: Thu, 11 Dec 1997 16:33:00 -0000 Message-id: <199712112353.SAA07152@melange.gnu.org> References: X-SW-Source: 1997-12/msg00683.html >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)