[Bug fortran/58270] Wrong code while accessing array elements in a global structure

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270

--- Comment #17 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I cannot agree with you. You are interpreting the code that may access the
> array beyond declared bounds as invalid, which is simply not true.

6.5 Use of data objects

... The value of a subscript in an array element shall be within the bounds for
its dimension.

where the "shall" means (as elsewhere in the standard) that it is the coder
responsibility to honor the constraint at run time.

> As you pointed it out before, unnamed common block may be declared larger
> elsewhere, so writing the dmem array beyond its first element may be a design
> decision and therefore may be perfectly legal. 

As above this is a wrong assumption: the design decision must be standard
conforming. When you write "common dmem(1)" you tell the compiler that 'dmem'
has only one element.

> The compiler has no clue about real size of unnamed common while compiling 
> buggy.f and bounds checking is optional.

When you write "common dmem(1)" you tell the compiler that 'dmem' has only one
element.

> I would also like to point it out that interpreting things this way 
> you do, 

This is not my interpretation, it is what the Fortran standard says.

> you exclude some older FORTRAN77 software (for example: quantum chemistry
> GAMESS), in which the lack of dynamic memory allocation was overcome using 
> the trick we are discussing here (mixing with C was needed). 

Well, I have used safer tricks to overcome the limitation.

> BTW, change the size of dmem to 2 in buggy.f and things start to work 
> correctly, although "out of bounds" memory accesses still do happen. 
> The problem occurs only if dmem is of size 1.

Because only for size 1 the optimizer can infer that valid uses will provide
the (1,1,1) triplet.

> Of course you (developers) may decide to ignore this problem anyway, 
> so if you do so, feel free to close this bug. I'm not going to reopen 
> it again, because I'm out of arguments. I'm also not competent enough 
> to tamper with the compiler.

What you can do is to look at the GCC manual and try to find the optimization
pass than enable the optimization you don't like and disable it. Note that most
optimizations are not part of the gfortran front-end.