Welcome to our forums
Simon
The Standard says that for AOA, an array that has already been allocated must be de-allocated and then re-allocated.
If I am wrong on this point then please let me know because AOA would be a whole lot simpler without this 'feature'.
That is my understanding of AOA too. In my example, AOA should not be taking place, because b was already allocated. My assumption (which may be incorrect) was that because b's shape changed, some form of reallocation was occurring. What I think should be happening is that if b is unallocated, AOA should occur; if b is allocated, then the shape of b must be conformant with the shape of the RHS (in this case of a(:,:,1)), and if it is non-conformat, a runtime error should occur. John's code is an example of a non-conformant, and I would expect that to crash - but perhaps only if compiler options request it to do so. When optimising, I guess the assumption is that it is the coder's responsibility to make sure the arrays are conformant.
Meanwhile, today I will try to run some tests using the compiler options, and will let you know what the results are ...
Initial results are that /inhibit_F2K 1 seems to disables BIND(C), while /-F2K disables quite a few other features, including the use of intrinsics in initialisation, various new intrinsic functions, DO CONCURRENT, square brackets, allocatable dummy arguments etc. The F2K documentation in the help pages is rather out of date, so there is a lot more that stops working with /-F2K than suggested there.