This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix problem causing g77 regressions
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 01 Dec 2001 12:56:06 +0100
- Subject: Re: Fix problem causing g77 regressions
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <10111281224.AA15212@vlsi1.ultra.nyu.edu>
Richard Kenner wrote:
> This fixes some g77 regressions caused by my last large change when tree
> checking is enabled.
Thanks for repairing the damage you yourself inflicted :-(
There's one left: auto1.f (see various i686 related testresults). This
one almost certainly is _also_ caused by changes in the SAVE_EXPR
handling (I'll explain below).
Because it might be hard to study this test-case, I simplified it for
you:
i = 40
call a1 (i)
end
subroutine a1 (n)
integer k0(n,3,2)
n = -1
do k = 1, 2
do j = 1, 3
do i = 1, 40
k0(i, j, k) = n
end do
end do
end do
end
When it is compiled with -O2 -g -fbounds-check you'll get the following
result:
Subscript out of range on file line 10, procedure auto2.f/a1.
Attempt to access the 1-th element of variable k0[subscript-1-of-3].
A bit a cryptic error message, because it had to be bolted on the
existing bounds checking infrastructure of libf2c. What it says is that
this array access (in the loop) exceeds the bounds of subscript 1 (i.e.,
i) by accessing the 1st element. This is bogus, of course, because
subscript 1 has an extent from 1 .. 40. The action that leads to this
bogus message is the assignment to n before the nested loop.
Prior to your changes, n-as-an-array-extent (line 5) would remain
unchanged when n was assigned to; this protection is arranged by
wrapping the variable extents of arrays in a SAVE_EXPR, which -
obviously - lost its protective power due to your changes.
Please debug this.
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)