* Results for egcs-971207 on m68k-next-nextstep3 @ 1997-12-10 7:08 Toon Moene 1997-12-10 13:36 ` fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] Dave Love 0 siblings, 1 reply; 12+ messages in thread From: Toon Moene @ 1997-12-10 7:08 UTC (permalink / raw) To: egcs First of all, the following completed perfectly: cd objdir make all-texinfo all-bison all-byacc all-binutils all-gas all-ld cd gcc make bootstrap make install-headers-tar cd .. make bootstrap3 [ I need this strange bootstrap procedure because of the header file curiosity in NEXTSTEP ] However, I got several warnings during the build: stage1/xgcc -Bstage1/ -c -DIN_GCC -O2 -g -DHAVE_CONFIG_H -I. -I. -I./config cplus-dem.c In file included from demangle.h:24, from cplus-dem.c:35: gansidecl.h:81: warning: `bcopy' redefined /NextDeveloper/Headers/ansi/string.h:119: warning: this is the location of the previous definition gansidecl.h:85: warning: `bzero' redefined /NextDeveloper/Headers/ansi/string.h:125: warning: this is the location of the previous definition gansidecl.h:89: warning: `bcmp' redefined /NextDeveloper/Headers/ansi/string.h:122: warning: this is the location of the previous definition gansidecl.h:93: warning: `rindex' redefined /NextDeveloper/Headers/ansi/string.h:116: warning: this is the location of the previous definition gansidecl.h:97: warning: `index' redefined /NextDeveloper/Headers/ansi/string.h:112: warning: this is the location of the previous definition and: ranlib: same symbol defined in more than one member in: tmplibgcc.a (table of contents will not be sorted) ranlib: file: tmplibgcc.a(_floatditf.o) defines symbol: __GLOBAL_$F$._libgcc2.c ranlib: file: tmplibgcc.a(_fixunstfdi.o) defines symbol: __GLOBAL_$F$._libgcc2.c ranlib: file: tmplibgcc.a(_ctors.o) defines symbol: __GLOBAL_$F$._libgcc2.c ranlib: file: tmplibgcc.a(_fixtfdi.o) defines symbol: __GLOBAL_$F$._libgcc2.c ranlib: file: tmplibgcc.a(_shtab.o) defines symbol: __GLOBAL_$F$._libgcc2.c also interesting is: filebuf.cc: In method `class filebuf * filebuf::open(const char *, int, int = 436)': filebuf.cc:114: warning: implicit declaration of function `int open(...)' and: stdiostream.cc: In method `long int stdiobuf::sys_read(char *, long int)': stdiostream.cc:77: warning: ANSI C++ forbids declaration `ch' with no type However, what did me in was the following: % cat dimstar.f subroutine star(aap, noot) dimension aap(*) end % /usr/test/bin/g77 -v dimstar.f Reading specs from /usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.02/specs gcc version egcs-2.91.02 971206 (gcc-2.8.0) /usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.02/f771 dimstar.f -fset-g77-defaults -quiet -dumpbase dimstar.f -version -fversion -o /usr/tmp/cc020259.s GNU F77 version egcs-2.91.02 971206 (gcc-2.8.0) (m68k-next-nextstep3) compiled by GNU C version egcs-2.91.02 971206 (gcc-2.8.0). GNU Fortran Front End version 0.5.22-19970929 dimstar.f: In subroutine `star': dimstar.f:1: subroutine star(aap, noot) ^ Array `aap' at (^) is too large to handle Seems that an earlier fix of this didn't make into the main (non-release) branch. Cheers, Toon. ^ permalink raw reply [flat|nested] 12+ messages in thread
* fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] 1997-12-10 7:08 Results for egcs-971207 on m68k-next-nextstep3 Toon Moene @ 1997-12-10 13:36 ` Dave Love 1997-12-10 16:43 ` Jeffrey A Law 0 siblings, 1 reply; 12+ messages in thread From: Dave Love @ 1997-12-10 13:36 UTC (permalink / raw) To: egcs >>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes: Toon> GNU Fortran Front End version 0.5.22-19970929 Toon> dimstar.f: In subroutine `star': Toon> dimstar.f:1: Toon> subroutine star(aap, noot) Toon> ^ Toon> Array `aap' at (^) is too large to handle Toon> Seems that an earlier fix of this didn't make into the main Toon> (non-release) branch. [I only noticed this by accident since since nothing in the subject caught my eye or score file.] It looks to me more like a problem with some recent backend change, though I haven't been able to debug it yet -- I always have trouble seeing the wood for the TREEs. Shouldn't the ChangeLog list individual changes from the gcc2 merge, BTW? In case someone else has a chance to sort it out before I do, the error report occurs (on my x86-linux box) because the TREE_OVERFLOW clause in ffecom_check_size_overflow_ from f/com.c returns true, run on g77.f-torture/compile/toon_1.f. (I think the original bug was cured by the addition of the `dummy' arg to that procedure, but I'm not sure since the test case doesn't contain a reference, hint. Perhaps Craig can confirm.) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] 1997-12-10 13:36 ` fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] Dave Love @ 1997-12-10 16:43 ` Jeffrey A Law 1997-12-11 11:14 ` Dave Love 0 siblings, 1 reply; 12+ messages in thread From: Jeffrey A Law @ 1997-12-10 16:43 UTC (permalink / raw) To: egcs > It looks to me more like a problem with some recent backend change, > though I haven't been able to debug it yet -- I always have trouble > seeing the wood for the TREEs. Shouldn't the ChangeLog list > individual changes from the gcc2 merge, BTW? It is most likely the gcc2 brought over in the last merge which try and flag arrays that are too big (compile/961203-1.c bug). We need to figure out how to make fortran work with that code, either by fixing the gcc2 changes or the fortran front end. jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] 1997-12-10 16:43 ` Jeffrey A Law @ 1997-12-11 11:14 ` Dave Love 1997-12-11 16:33 ` Craig Burley 0 siblings, 1 reply; 12+ messages in thread From: Dave Love @ 1997-12-11 11:14 UTC (permalink / raw) To: egcs >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes: Jeffrey> It is most likely the gcc2 brought over in the last merge Jeffrey> which try and flag arrays that are too big Jeffrey> (compile/961203-1.c bug). Ah. Doubtless. Jeffrey> We need to figure out how to make fortran work with that Jeffrey> code, either by fixing the gcc2 changes or the fortran front Jeffrey> end. 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. I think Fortran isn't really usable until this is resolved somehow because that construct is very common. I doubt I can be much help other than maybe explaining the fortran issues if a wizard is able to look into it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] 1997-12-11 11:14 ` Dave Love @ 1997-12-11 16:33 ` Craig Burley 1997-12-12 10:18 ` Dave Love ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Craig Burley @ 1997-12-11 16:33 UTC (permalink / raw) To: egcs >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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] 1997-12-11 16:33 ` Craig Burley @ 1997-12-12 10:18 ` Dave Love 1997-12-12 18:04 ` Craig Burley [not found] ` <rzqd8j2zb5m.fsf.cygnus.egcs@djlvig.dl.ac.uk> 1997-12-15 23:18 ` g77 assumed array patch [was: fortran regression] Richard Henderson 2 siblings, 1 reply; 12+ messages in thread From: Dave Love @ 1997-12-12 10:18 UTC (permalink / raw) To: egcs >>>>> "Craig" == Craig Burley <burley@gnu.org> writes: Craig> I believe the problem is that g77 is telling the back end that Craig> "REAL A(*)" is really REAL A(1:2147483647) Yes, that's definitely what it does. Craig> One of the problems we've noticed as being likely to occur Craig> once this is resolved is that there's some confusion as to Craig> whether and how the DWARF (2?) debugging format supports this Craig> construct. At least on the x86 linux, only stabs works at all for fortran. gdb gets an internal error if you try it with dwarf. (-gdwarf-2 on this redhat box produces an assembler error; I suppose I need a different binutils.) Anyhow, gdb's fortran support isn't compatible with g77's conventions even when g77 is able to generate appropriate debugging info. Unfortunately you really have to operate in C mode, knowing the relevant conventions, to debug fortran successfully and you still lose in this case. Craig> Hopefully someone knowledgable about that will chime in by the Craig> time it becomes an issue. Hear, hear. (bug-gdb was previously silent on the matter.) >> I think Fortran isn't really usable until this is resolved somehow >> because that construct is very common. Craig> Lots of old code uses this construct (called "assumed Craig> arrays"), plus some new code as well. Given that we don't do f90 :-(, isn't the `old' code is what just uses dimensions of `(1)' with this the new-fangled way? :-/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] 1997-12-12 10:18 ` Dave Love @ 1997-12-12 18:04 ` Craig Burley 0 siblings, 0 replies; 12+ messages in thread From: Craig Burley @ 1997-12-12 18:04 UTC (permalink / raw) To: egcs > Craig> Lots of old code uses this construct (called "assumed > Craig> arrays"), plus some new code as well. > >Given that we don't do f90 :-(, isn't the `old' code is what just uses >dimensions of `(1)' with this the new-fangled way? :-/ Ok, "REAL A(1)" is the old-old way, "REAL A(*)" is the old way, "REAL A(N)" is the new way, "REAL, DIMENSION(N) :: A" is the new-new way. :) By this I mean that assumed-size arrays are often trivially replacable by the semantically superior adjustable arrays ("REAL A(N)"), though of course before either existed, people often used "REAL A(1)". Though there are still (in F77 anyway) valid uses of assumed-sized arrays that are not easily replaced by adjustable arrays. tq vm, (burley) ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <rzqd8j2zb5m.fsf.cygnus.egcs@djlvig.dl.ac.uk>]
* Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] [not found] ` <rzqd8j2zb5m.fsf.cygnus.egcs@djlvig.dl.ac.uk> @ 1997-12-12 15:46 ` Jason Merrill 1997-12-13 10:44 ` Dave Love 0 siblings, 1 reply; 12+ messages in thread From: Jason Merrill @ 1997-12-12 15:46 UTC (permalink / raw) To: egcs >>>>> Dave Love <d.love@dl.ac.uk> writes: > At least on the x86 linux, only stabs works at all for fortran. gdb > gets an internal error if you try it with dwarf. (-gdwarf-2 on this > redhat box produces an assembler error; I suppose I need a different > binutils.) I don't think anyone's added specific fortran support to gcc/dwarf2out.c. The dwarf 2 spec can be found in ftp://sgigate.sgi.com/pub/dwarf if anyone's interested in doing that work. Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] 1997-12-12 15:46 ` Jason Merrill @ 1997-12-13 10:44 ` Dave Love 0 siblings, 0 replies; 12+ messages in thread From: Dave Love @ 1997-12-13 10:44 UTC (permalink / raw) To: egcs >>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes: Jason> I don't think anyone's added specific fortran support to Jason> gcc/dwarf2out.c. I don't think (Craig?) that g77 currently tries to generate fortran-specific debugging stuff, though it's a while since I looked. (The fortran-specifics come from what gdb assumes with `lang fortran' AFAIR.) Thanks for the pointer, anyway. Should we be disabling non-stabs -g for g77, and generating an error message, perhaps? ^ permalink raw reply [flat|nested] 12+ messages in thread
* g77 assumed array patch [was: fortran regression] 1997-12-11 16:33 ` Craig Burley 1997-12-12 10:18 ` Dave Love [not found] ` <rzqd8j2zb5m.fsf.cygnus.egcs@djlvig.dl.ac.uk> @ 1997-12-15 23:18 ` Richard Henderson 1997-12-18 23:19 ` Jeffrey A Law 2 siblings, 1 reply; 12+ messages in thread From: Richard Henderson @ 1997-12-15 23:18 UTC (permalink / raw) To: Craig Burley; +Cc: egcs On Thu, Dec 11, 1997 at 06:53:48PM -0500, Craig Burley wrote: > 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. The following patch implements this suggestion. It compiles the null test case subroutine star(aap, noot) dimension aap(*) end well enough; I'm about to sick it on SpecFP (which is actually my main impetus to fix this -- I want to see how well my giv patch works ;-) So we'll see how well it does on real code soon enough. I believe I've gotten all of the cases elsewhere in the compiler that were assuming an upper bound existed. I may have missed some, and I may have changed some that could not possibly be called on a range type. Someone else ought to look through and verify that. r~ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: g77 assumed array patch [was: fortran regression] 1997-12-15 23:18 ` g77 assumed array patch [was: fortran regression] Richard Henderson @ 1997-12-18 23:19 ` Jeffrey A Law 1997-12-19 12:37 ` Dave Love 0 siblings, 1 reply; 12+ messages in thread From: Jeffrey A Law @ 1997-12-18 23:19 UTC (permalink / raw) To: rth; +Cc: egcs, Craig Burley In message < 19971215230724.05958@dot.cygnus.com >you write: > > 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. > > The following patch implements this suggestion. > > It compiles the null test case > > subroutine star(aap, noot) > dimension aap(*) > end [ ... ] > Mon Dec 15 22:46:19 1997 Richard Henderson <rth@cygnus.com> > > G77 ChangeLog: > * com.c (ffecom_sym_transform_): Assumed arrays have no upper bound. > > GCC ChangeLog: > * tree.c (build_range_type): Allow creation of ranges with no maximum. > * dbxout.c (dbxout_range_type): Handle missing TYPE_MAX_VALUE. > * dwarf2out.c (add_subscript_info): Likewise. > * dwarfout.c (subscript_data_attribute, byte_size_attribute): Likewise. > * sdbout.c (plain_type_1): Likewise. > * stmt.c (pushcase_range, all_cases_count, node_has_high_bound): > Likewise. > * fold-const.c (int_const_binop, fold_convert, make_range, fold): > Likewise. THanks. I went ahead and installed this patch. If we're missing a case I'm sure we'll find out soon enough. I do worry a little about the "hope debuggers can deal" issues with an unspecified high bound. Maybe we should set an artificial one if some debuggers don't handle unspecified bounds correctly. jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: g77 assumed array patch [was: fortran regression] 1997-12-18 23:19 ` Jeffrey A Law @ 1997-12-19 12:37 ` Dave Love 0 siblings, 0 replies; 12+ messages in thread From: Dave Love @ 1997-12-19 12:37 UTC (permalink / raw) To: egcs >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes: Jeffrey> I do worry a little about the "hope debuggers can deal" Jeffrey> issues with an unspecified high bound. Maybe we should set Jeffrey> an artificial one if some debuggers don't handle unspecified Jeffrey> bounds correctly. Well, gdb definitely still can't cope with the debugging info produced, though the bound now appears as -1 rather than 2147483647. FWIW, this with g77 -g using the rth patch: real a(10) do i=1,10 a(i)=i end do call foo(a) end subroutine foo(a) real a(*) print *, a(1) end produces: Breakpoint 2, foo_ (a=0xbffff590) at /tmp/x.f:9 9 print *, a(1) Current language: auto; currently fortran (gdb) whatis a type = PTR TO -> ( real*4 (-1)) (gdb) set lang c Warning: the current language does not match this frame. (gdb) p a[1] Segmentation fault $ If I compile the same thing with (an old) sunpro f77 on sunos4 (stabs), gdb will show me something sensible (which I didn't expect :-)): Breakpoint 2, foo (a=()) at x.f:9 9 print *, a(1) (gdb) whatis a type = real*4 (0:-1) (gdb) p a $1 = () (gdb) p a(1) $2 = 1 (gdb) I don't remember what gdb is doing here (or expecting) in the the g77 case, though I did follow it once. gdb's fortran conventions are those of some motorola compiler AFAIK. [You can't use `p a(1)' with lang fortran on the g77 output because it's interpreted as a function call.] I'll be happy to help sort it out if anyone has good ideas how to proceed. There are some other problems with g77 debugging info which probably need to be sorted out in the backend; bits of the fortran frontend currently use symbols like IF_SOMEONE_GETS_DEBUGGING_SUPPORT_WORKING :-(. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1997-12-19 12:37 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-12-10 7:08 Results for egcs-971207 on m68k-next-nextstep3 Toon Moene 1997-12-10 13:36 ` fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3] Dave Love 1997-12-10 16:43 ` Jeffrey A Law 1997-12-11 11:14 ` Dave Love 1997-12-11 16:33 ` Craig Burley 1997-12-12 10:18 ` Dave Love 1997-12-12 18:04 ` Craig Burley [not found] ` <rzqd8j2zb5m.fsf.cygnus.egcs@djlvig.dl.ac.uk> 1997-12-12 15:46 ` Jason Merrill 1997-12-13 10:44 ` Dave Love 1997-12-15 23:18 ` g77 assumed array patch [was: fortran regression] Richard Henderson 1997-12-18 23:19 ` Jeffrey A Law 1997-12-19 12:37 ` Dave Love
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).