This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment
On Tue, Nov 25, 2008 at 10:41:02PM +0100, Toon Moene wrote:
> Steve Kargl wrote:
> >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.
> Indeed you don't seem to understand.
> Exceeding array bounds is wrong in general. However, it's most heinous
> when it also means you address outside of the array's extent (i.e., you
> either read bogus data outside of the array or you write (shudder)
> outside the array.
> This is sufficiently more aggravating that making a distinction would be
> 1. Warn (or error) on exceeding a single array bound.
> 2. Warn (or error) on an access/store from/to an array be outside its
> The last one at least warns if you are to read a completely unrelated
> value, but more importantly, would *write* over an unrelated value.
> The first one is nice to have to know that your program (in this
> respect) is Standard conforming.
Perhaps, I've had too little or more likely too much caffiene, today.
But, I still don't see what distinction you're trying to draw between
-fbounds-check and -fcheck-size, because -fbounds-check correctly
identifies the program is doing something that is possibly an error.
A = 1.0
SUBROUTINE SUB(A, N)
REAL A(N, N)
With -fbounds-check, the above dies with a runtime error. You then
fix your code:
SUBROUTINE SUB(A, N) or SUBROUTINE SUB(A, N)
REAL A(N*N) REAL A(N,N), B(N*N)
PRINT*,A(N*N) B = reshape(a,(/n*n/))
Do your desired semantics for -fcheck-size match the following?
% gfortran -fcheck-size -o z a.f
Warning: Array element 'A(10,10)' accessed as 'A(1,100)' in subprogram
SUB at line 3.
Even if the above warning is changed to a runtime error, I find nothing
remarkably compelling to merit the addition of yet-another-legacy option
into gfortran. IMHO, gfortran should not follow g77 down the path of
a kitchen sink of options. Broken legacy code will remain broken legacy
code if compilers add dubious options because programmers are too lazy to
fix the issue.
Of course, if you or someone else produces a patch to implement
-fcheck-size, I no longer have any standing in gfortran development,
so I can't stop inclusion of such an option.