This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment

On Tue, Nov 25, 2008 at 07:40:20PM +0100, Toon Moene wrote:
> Steve Kargl wrote:
> >On Mon, Nov 24, 2008 at 10:45:51PM +0100, Toon Moene wrote:
> >>One option that would help me (and probably countless others) to debug 
> >>legacy code is an -fcheck-size option.
> >>
> >>The meaning of this option would be:
> >>
> >>        Check if array references fall within the extent of the array.
> >>
> >>        REAL A(10,10)
> >>        A = 1.0
> >>        CALL SUB(A,10)
> >>        END
> >>        SUBROUTINE SUB(A, N)
> >>        REAL A(N, N)
> >>        PRINT*,A(1,N*N)
> >>        END
> >
> >Heh?
> >
> >troutmask:kargl[203] gfc -fbounds-check t.f90
> >troutmask:kargl[204] ./a.out 
> >At line 8 of file t.f90
> >Fortran runtime error: Array reference out of bounds for array 'a', upper 
> >bound of dimension 2 exceeded (100 > 10)
> Yep, that's the problem - array bounds checking "catches" this, while 
> the run-of-the-mill index computation let this fall within the extent of 
> the array.
> Parts of the code I have to maintain were written 30-40 years ago. 
> Apparently this was accepted practice then (and it would still work today).

I still don't get what you want.  Are the semantics of -fcheck-size
to permit the above code to compile and run?  I would prefer that
gfortran does not grow a bunch of crufty questionable options because
no one in 30 years has bother to fix their code.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]