This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3]
- To: egcs at cygnus dot com
- Subject: fortran regression [was Re: Results for egcs-971207 on m68k-next-nextstep3]
- From: Dave Love <d dot love at dl dot ac dot uk>
- Date: 10 Dec 1997 21:34:13 +0000
- Organization: Daresbury Laboratory, Warrington WA4 4AD, UK
- References: <9712101506.AA20265@moene.indiv.nluug.nl>
- Reply-To: egcs at cygnus dot com
>>>>> "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.)