Re: g77 problem in egcs-ss-970828

Re: g77 problem in egcs-ss-970828

[Mumit Khan]

Toon Moene  writes:
> I'm sending this to egcs, because I'm not entirely sure that this  
> front end bug is *not* caused by the snapshots C compiler  
> miscompiling the g77 frontend.
> 
> Given the following Fortran routine:
> 
>       SUBROUTINE AAP(NOOT)
>       DIMENSION NOOT(*)
>       END


I can verify this problem on at 2 other platforms, and it does not happen
with the previous snapshots (2.90.00-2.90.02) on either of these machines
(i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).

Mumit

Re: A patch for test case

[Jeffrey A Law]

  In message you write:
  > Without this patch, it will fail on any dynamic linker which
  > uses global strcmp ().
Tege comments?


  > -- 
  > H.J. Lu (hjl@gnu.ai.mit.edu)
  > ---
  > Index: gcc/testsuite/gcc.c-torture/execute/921007-1.c
  > ===================================================================
  > RCS file: /home/work/cvs/gnu/egcs/gcc/testsuite/gcc.c-torture/execute/92100
  > 7-1.c,v
  > retrieving revision 1.1.1.1
  > diff -u -r1.1.1.1 921007-1.c
  > --- 921007-1.c	1997/08/26 00:21:22	1.1.1.1
  > +++ 921007-1.c	1997/08/28 19:49:30
  > @@ -1,4 +1,4 @@
  > -int strcmp(){return-1;}
  > +static int strcmp(){return-1;}
  >  #define strcmp __builtin_strcmp
  >  main()
  >  {

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message you write:
  > To see how this is supposed to work, see the bfd sources.  The gcc
  > implementation was copied from bfd, but is incomplete.
  > 
  > I knew that we were missing this stuff:
  > 	#ifdef NEED_DECLARATION_FREE
  > 	extern void free ();
  > 	#endif
  > 
  > But now I see that we are also missing this stuff:
  > 	#ifdef HAVE_STDLIB_H
  > 	#include 
  > 	#endif
Yup.  That's exactly the problem.

  > If you want, I am willing to take this problem off your hands.
Well, I've added the ones that were absolutely necessary to get
egcs building again.  We really need to go through and add them
to the rest of the compiler though.


Jeff

Re: g77 problem in egcs-ss-970828

[Dave Love]

>>>>> "Toon" == Toon Moene  writes:

 >> SUBROUTINE AAP(NOOT)
 >> DIMENSION NOOT(*)
 >> END

 Toon> And Mumit Kahn replied:

 >> I can verify this problem on at 2 other platforms, and
 >> it does not happen with the previous snapshots
 >> (2.90.00-2.90.02) on either of these machines
 >> (i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).

 Toon> This makes it highly unlikely that it is caused by miscompilation  
 Toon> by the snapshot's C compiler.

 Toon> Craig, do you now where to look for this g77 front end bug ?

It doesn't occur with the gcc 2.7-based g77 patched up to g77-970827
on x86 linux.

I don't know if it's relevant, but there are longstanding problems
describing assumed-size and adjustable arrays about which there's an
essay somewhere in f/com.c IIRC.

Re: g77 problem in egcs-ss-970828

[Jeffrey A Law]

  In message you write:
  > Toon Moene  writes:
  > > I'm sending this to egcs, because I'm not entirely sure that this  
  > > front end bug is *not* caused by the snapshots C compiler  
  > > miscompiling the g77 frontend.
  > > 
  > > Given the following Fortran routine:
  > > 
  > >       SUBROUTINE AAP(NOOT)
  > >       DIMENSION NOOT(*)
  > >       END
  > 
  > 
  > I can verify this problem on at 2 other platforms, and it does not happen
  > with the previous snapshots (2.90.00-2.90.02) on either of these machines
  > (i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).
It's a bad interaction between the fold-const.c changes to detect
overflows in array index & size calculations and the g77 front end
(I brought the fold-const.c changes over between the 970825 and 970828
snapshots.

Backing out the fold-const.c (and c-decl.c) changes fixes the problem.
I think that's the way to go; we'll bring the fold-const and c-decl
changes back into egcs after the first release when we can analyze
this problem further.

jeff

Re: g77 problem in egcs-ss-970828

[Jeffrey A Law]

  In message you write:
  > I'm sending this to egcs, because I'm not entirely sure that this  
  > front end bug is *not* caused by the snapshots C compiler  
  > miscompiling the g77 frontend.
  > 
  > Given the following Fortran routine:
  > 
  >       SUBROUTINE AAP(NOOT)
  >       DIMENSION NOOT(*)
  >       END
  > 
  > (for non-Fortraners, NOOT(*) means something like noot[] in C) I  
  > get the following error from g77:
I'll look at it.  Either the code to catch too-large array sizes
is incorrectly giving an error, or something is wrong in the fortran
front end (which was upgraded for this snapshot).

jeff

Re: g77 problem in egcs-ss-970828

[Toon Moene]

I wrote:

> I'm sending this to egcs, because I'm not entirely sure that this  
> front end bug is *not* caused by the snapshots C compiler
> miscompiling the g77 frontend.
>
> Given the following Fortran routine:
>
>       SUBROUTINE AAP(NOOT)
>       DIMENSION NOOT(*)
>       END

And Mumit Kahn replied:

>  I can verify this problem on at 2 other platforms, and
>  it does not happen with the previous snapshots
>  (2.90.00-2.90.02) on either of these machines
>  (i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).

This makes it highly unlikely that it is caused by miscompilation  
by the snapshot's C compiler.

Craig, do you now where to look for this g77 front end bug ?

TIA,
Toon

g77 problem in egcs-ss-970828

[Toon Moene]

I'm sending this to egcs, because I'm not entirely sure that this  
front end bug is *not* caused by the snapshots C compiler  
miscompiling the g77 frontend.

Given the following Fortran routine:

      SUBROUTINE AAP(NOOT)
      DIMENSION NOOT(*)
      END

(for non-Fortraners, NOOT(*) means something like noot[] in C) I  
get the following error from g77:

/usr/test/bin/g77 -v array2large.f
g77 version 0.5.21-19970826
 /usr/test/bin/gcc -v -xf77 array2large.f -xnone -lf2c -lm
Reading specs from  
/usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.90.03/specs
gcc version egcs-2.90.03 970828 (gcc2-970802 experimental)
 /usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.90.03/f771  
array2large.f -fset-g77-defaults -quiet -dumpbase array2large.f  
-version -fversion -o /usr/tmp/cc022314.s
GNU F77 version egcs-2.90.03 970828 (gcc2-970802 experimental)  
(m68k-next-nextstep3) compiled by GNU C version egcs-2.90.03 970828  
(gcc2-970802 experimental).
GNU Fortran Front End version 0.5.21-19970826
array2large.f: In subroutine `aap':
array2large.f:1:
         SUBROUTINE AAP(NOOT)
                        ^
Array `noot' at (^) is too large to handle

I picked up egcs-core-970828.tar.gz and egcs-g77-970828.tar.gz from  
the anonymous ftp site, unpacked and did a

% setenv CC cc; ./configure --prefix=/usr/test; make

Because that didn't do a make bootstrap in the gcc directory, I  
went into that directory and did

% make bootstrap LANGUAGES=c CFLAGS="-g -O3"

That worked; the subsequent `make compare' completed without error.

Then I built g77, thusly:

% make CC="stage2/xgcc -Bstage2/" CFLAGS="-O -g -O3" LDFLAGS=""  
libdir=/usr/test/lib STAGE_PREFIX=stage2/ LANGUAGES="c f77"

and installed the stuff.

Hope this is accurate enough,
Toon.