Submodule+coarray bug with IVF 16.0

[OP1]

The following code triggers compiler error #8361 (A coarray or an object with a coarray ultimate component shall be a dummy argument or have the ALLOCATABLE or SAVE attribute.) for coarray J. I think this is incorrect, but I may be wrong.

Using SAVE for J eliminates this error message.

MODULE A
INTEGER :: I

END MODULE A

SUBMODULE (A) B
INTEGER :: J

END SUBMODULE B

PROGRAM MAIN
USE A
END PROGRAM MAIN

[Steven_L_Intel1]

Please use Intel Premier Support for reporting issues with the beta. I will pass this on to the developers, but it helps us track things better if you use IPS for beta issues. The compiler is incorrect here - variables declared in submodules have SAVE implicitly. Issue ID is DPD200370102.

[Steven_L_Intel1]

This is fixed in version 16, available now.

[CAPyC2015]

We have just installed update 2 of version 16 and still have the problem:

error #8361: A coarray or an object with a coarray ultimate component shall be a dummy argument or have the ALLOCATABLE or SAVE attribute. [LOCAL_N] INTEGER ( KIND = isingle) :: local_N

Why is it necessary to declare the coarrays as SAVE?

[Steven_L_Intel1]

The problem as described in the original post has been fixed, so you have a different problem. 

The standard requires that a coarray or a variable of derived type that has a coarray subcomponent (even many levels down) must be either a dummy argument or have the ALLOCATABLE or SAVE attributes. (F2008 constraint C526) If LOCAL_N is a local variable in a subroutine or function, it must have SAVE. The idea is that coarrays exist across all the images and one can't have a coarray wink in and out of existence as the program executes.

[CAPyC2015]

Thank you Steve, We are learning to use coarrays, and still having some issues. Had not though about it until your reply. The rule seems sound.

Thank you very much for the quick reply.