[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368

--- Comment #57 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #56)
> > >       FUNCTION FOO(I, J)
> > >       COMMON /BLK/ K(1)
> > >       FOO = K(I) + K(J) + K(2*I) + K(2*J)
> > >       END FUNCTION
> 
> This piece of code is also invalid (out of bound access to K): K(I) + K(J)
> is valid iff I=J=1, but K(2*I) + K(2*J) is always accessing elements outside
> the array K(1).
> 
> > The correct solution to me is to detect the unequal sizes and convert
> > the COMMON /BLK/ K(1) to the larger size, ie K(64).
> 
> This can be done at link time only if the two TU are in different files.

There are two kinds of people to consider here.

One is sPEC.  I think they are wrong in their policy, but I doubt we are
going to change it.

The other are normal users, who have an existing code base relying
on such behavior.  What can we do for them?

I think it would be appropriate to warn (with -Wall) if code

- uses this idiom (one-element array as trailing common block member)

- uses a non-constant expression to access an element

while telling the user how to get around this issue.

If we can prove that the access is out of bounds, then we
could also issue an error.

This appears to be a frequent idiom in old-style Fortran, which is
not always easy to fix in legacy code.  We would do a large part
of our user base a disservice if there was no way to get around this.