forums.silverfrost.com

[simon]

Understood Paul. Thanks for looking into this. I am loading a and b into the separate subprograms because typically the module contains a large number of subprograms, and I am looking to make available to each subprogram only those variables that it needs. If a and b are loaded before the CONTAINS statement, they become available to the every subprogram, which may not be desirable. Regardless, if s1 and s2 are in separate modules I get the same problem with the shape of b changing.

[PaulLaidler]

Simon

The failure concerns "allocate on assignment" (AOA) and the statement b(:,:) = a(:,:,1).

When using separate and local USE statements a work-around is to either 1) switch off /F2K which is on by default (add /-F2K) or 2) inhibit AOA with "/inhibit_F2K 1".

At the moment I don't know if FTN95 should be attempting AOA in this context, nor why it fails.

The problem with AOA is that it has the potential to break existing code (or learned expectations) even when all related compiler bugs have been fixed. There might be a case for having AOA switched off by default with a separate option to switch it on. This would have an impact on users who have started to use AOA because it would stop working until the new switch is applied.

[JohnCampbell]

Paul,

For the example I posted earlier in this thread, after "b(:,:) = a(:,:,1)", both FTN95 and Gfortran report SHAPE(b) as [4,6] and not [4,7], which suggests to me that AOA is not being implemented in my example.

I am not familiar with AOA to be confident in this claim.

John

[PaulLaidler]

John: Thanks for the feedback.

Simon: This failure has now been fixed for the next release of FTN95 (I can provide an new FTN95 straight away if needed).

When the array A is allocatable, its size is not known at compile time. With the fix, FTN95 will not attempt AOA in this context (i.e. that of the original reported failure).

[simon]

Hi Paul,

MANY thanks for your diligent work on this problem. Let me try the compiler switches and see what that effect is. If AOA has to be switched off, I can deal with that more easily than with this problem since I am only using AOA in a few cases. If I am still having difficulties I will get back to you about accessing the fix.

Given that b is already allocated, how come this is classified as an AOA issue?

[PaulLaidler]

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".

[simon]

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.