https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #58 from rguenther at suse dot de <rguenther at suse dot de> --- On February 19, 2016 6:48:38 AM GMT+01:00, "tkoenig at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >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. We already warn about mismatches sizes at LTO link time
