public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* g77 problem in egcs-ss-970828
@ 1997-08-29 13:47 Toon Moene
  1997-08-29 15:01 ` Fix for expr.c prototype bug Jeffrey A Law
  1997-08-29 15:18 ` genflags / genemit inconsistency Jeffrey A Law
  0 siblings, 2 replies; 8+ messages in thread
From: Toon Moene @ 1997-08-29 13:47 UTC (permalink / raw)
  To: egcs

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fix for expr.c prototype bug
  1997-08-29 13:47 g77 problem in egcs-ss-970828 Toon Moene
@ 1997-08-29 15:01 ` Jeffrey A Law
  1997-08-29 15:18 ` genflags / genemit inconsistency Jeffrey A Law
  1 sibling, 0 replies; 8+ messages in thread
From: Jeffrey A Law @ 1997-08-29 15:01 UTC (permalink / raw)
  To: egcs

  In message you write:
  > This patch fixes the expr.c prototype bug for real, so that the prototype
  > for insn_gen_function can be reenabled.
  > 
  > 
  > 1997-08-27  Andreas Schwab  
  > 
  > 	* expr.h (insn_gen_function): Reenable prototype.
  > 
  > 	* expr.c (move_by_pieces_1, clear_by_pieces_1): Fix prototype of
  > 	first parameter.
Thanks, I've installed this patch.

jeff

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: genflags / genemit inconsistency
  1997-08-29 13:47 g77 problem in egcs-ss-970828 Toon Moene
  1997-08-29 15:01 ` Fix for expr.c prototype bug Jeffrey A Law
@ 1997-08-29 15:18 ` Jeffrey A Law
  1 sibling, 0 replies; 8+ messages in thread
From: Jeffrey A Law @ 1997-08-29 15:18 UTC (permalink / raw)
  To: egcs

  In message you write:
  > For patterns like this one:
  > 
  > (define_expand "casesi_jump"
  >   [(parallel [(set (pc) (match_operand:SI 0 "register_operand" "r"))
  >               (use (label_ref (match_operand 2 "" "")))])]
  > 
  > genflags generates prototypes that don't match the function definition
  > that genemit creates: the function definition for this example has three
  > arguments, while the prototype has only two.
Why not just fix the pattern?  Seems to me this patch caters to
broken machine descriptions that we should instead fix.

jeff

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: g77 problem in egcs-ss-970828
  1997-08-30  5:43 Results for haifa-enabled egcs-970828 gcc testsuite on sparc-sun-solaris2.5 Alexandre Oliva
@ 1997-08-30 11:27 ` Dave Love
  0 siblings, 0 replies; 8+ messages in thread
From: Dave Love @ 1997-08-30 11:27 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: g77 problem in egcs-ss-970828
  1997-08-29 18:12 A vtable thunks bug Ulrich Drepper
@ 1997-08-29 18:59 ` Jeffrey A Law
  0 siblings, 0 replies; 8+ messages in thread
From: Jeffrey A Law @ 1997-08-29 18:59 UTC (permalink / raw)
  To: egcs

  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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: g77 problem in egcs-ss-970828
  1997-08-29 16:46 Toon Moene
@ 1997-08-29 17:20 ` Jeffrey A Law
  0 siblings, 0 replies; 8+ messages in thread
From: Jeffrey A Law @ 1997-08-29 17:20 UTC (permalink / raw)
  To: egcs

  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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: g77 problem in egcs-ss-970828
@ 1997-08-29 16:46 Toon Moene
  1997-08-29 17:20 ` Jeffrey A Law
  0 siblings, 1 reply; 8+ messages in thread
From: Toon Moene @ 1997-08-29 16:46 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: g77 problem in egcs-ss-970828
@ 1997-08-29 15:40 Mumit Khan
  0 siblings, 0 replies; 8+ messages in thread
From: Mumit Khan @ 1997-08-29 15:40 UTC (permalink / raw)
  To: egcs

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1997-08-30 11:27 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-29 13:47 g77 problem in egcs-ss-970828 Toon Moene
1997-08-29 15:01 ` Fix for expr.c prototype bug Jeffrey A Law
1997-08-29 15:18 ` genflags / genemit inconsistency Jeffrey A Law
1997-08-29 15:40 g77 problem in egcs-ss-970828 Mumit Khan
1997-08-29 16:46 Toon Moene
1997-08-29 17:20 ` Jeffrey A Law
1997-08-29 18:12 A vtable thunks bug Ulrich Drepper
1997-08-29 18:59 ` g77 problem in egcs-ss-970828 Jeffrey A Law
1997-08-30  5:43 Results for haifa-enabled egcs-970828 gcc testsuite on sparc-sun-solaris2.5 Alexandre Oliva
1997-08-30 11:27 ` g77 problem in egcs-ss-970828 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).