Results for egcs-971207 on m68k-next-nextstep3

Results for egcs-971207 on m68k-next-nextstep3

[Toon Moene]

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.

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

[Dave Love]

>>>>> "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.)

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

[Jeffrey A Law]

  > 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

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

[Dave Love]

>>>>> "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.

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

[Craig Burley]

>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)

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

[Dave Love]

>>>>> "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?  :-/

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

[Jason Merrill]

>>>>> 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

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

[Craig Burley]

> 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)

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

[Dave Love]

>>>>> "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?

g77 assumed array patch [was: fortran regression]

[Richard Henderson]

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~

Re: g77 assumed array patch [was: fortran regression]

[Jeffrey A Law]

  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

Re: g77 assumed array patch [was: fortran regression]

[Dave Love]

>>>>> "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 :-(.