Unusual allocatable array behaviour

[Dishaw__Jim]

Let me preface this with the caveat that I have not researched the language spec to determine if this is the correct behaviour. Consider the following program

program test
implicit none
! Variables
real, allocatable :: v1(:)
real, allocatable :: v2(:)
real, allocatable :: v3(:)
real, allocatable :: m(:,:)
integer :: i

allocate(v1(4),v2(2),v3(4),m(4,4))

m = 0.0
forall(i=1:4) m(i,i) = 1.0
v3(1) = 1.0
v3(2) = 1.0
v3(3) = 0.0
v3(4) = 0.0

! This should work
v1 = MATMUL(m,v3)

! This should not work
v2 = MATMUL(m, v3)

end program test

If I have array bounds checking turned on, the above code will execute with no exception being raised. If the allocatable arrays are replaced with static arrays of the same size, then the compiler generates an error on the "v2 = MATMUL(m v3)" statement, which is the behaviour that I expect.

Why does the bounds checking not trap the mismatched sizes?

[Steven_L_Intel1]

The language says you're not allowed to do this - it doesn't say what the compiler must do if you have this mismatch. Sometimes bounds checking will detect the problem, but not always. We have not yet implemented "shape checking" which is what you really need here.

[Dishaw__Jim]

At face value it should generate an array bounds error. The arrays m and v3 are of the correct size while the array v2 is to short to contain the result. The only reason that I can think of why it would not generate an array bounds error is if the result of the MATMUL is stored in a temporary location and then copied to the destination array. If the copy checks the size of the destination, it would be smart enough to copy the appropriate number of bytes.

On the other hand, if the result of the MATMUL is being blasted into the destination array, then it is writing past the end of the array.

[Steven_L_Intel1]

If I correctly recall the explanation, the compiler picks either the left side or the right side to determine how many elements to move, since it should be able to assume these are the same. It is something we know needs improvement.