The attached program produce memory corruption at runtime because of an expression between 2 arrays of different shape using array section. I'm not sure if it is standard conforming or not, so I'm reporting it as a bug; the program executes OK with pgf90 and ifort (on Linux) and xlf90 (on AIX).
Created attachment 17692 [details] Test program gfortran work fine if I change the line; 'listgeonm(1,:) = geonm(:,1)' to 'listgeonm(1,:) = geonm(1:p_bgeo_top,1)'
If you compile the code in comment #1 with '-fbounds-check', you get: At line 32 of file pr39894.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 2 of array 'listgeonm' (18/999) (off by one, see pr39872). So the code is invalid and have to be fixed as noticed in comment #1. Note that I don't see the "memory corruption" on i686-apple-darwin9, but this is pure luck.
(In reply to comment #2) > If you compile the code in comment #1 with '-fbounds-check', you get: > > At line 32 of file pr39894.f90 > Fortran runtime error: Array bound mismatch, size mismatch for dimension 2 of > array 'listgeonm' (18/999) > Thanks, I've seen that too. But bounds checking on the other compilers I have access to doesn't show any problem. I was hoping gfortran can be smarter in this situations like this, and use just the first portion of the array on the right side that fits the shape of the array section on the left of the assignment statement.
> But bounds checking on the other compilers I have access to doesn't show any problem Are you sure about that? If you use bound-checking on any compiler supporting it, you should get an error (at least a warning). > I was hoping gfortran can be smarter in > this situations like this, and use just the first portion of the array on the > right side that fits the shape of the array section on the left of the > assignment statement. Again, I don't think any compiler is smart with this respect. If one is, it should emit a warning about the use of the extension. Now as I said in comment #2, on i686-apple-darwin9 the invalid and valid codes give the same output, but it is not because gfortran is smarter on this platform than on yours, but only because the memory layouts are different and that the extra data are written on i686-apple-darwin9 in a place that does not cause a problem. Final note, you should close this pr as invalid, TIA.
The Fortran 95 standard states: 7.5.1.4 Intrinsic assignment conformance rules For an intrinsic assignment statement, variable and expr shall conform in shape, and if expr is an array, variable shall also be an array. The types of variable and expr shall conform with the rules of Table 7.9. This is not a constraint, so a compiler is not required to generate a warning or an error. It can do anything, including corrupt memory. As Dominique suggested, one should use the -fbounds-check option while developing code.