Well, as far as I understood from the last comments, the standard seems not to be “bugged”, maybe just very difficult to follow to all the consequences here. But if it would eventually be determined that is “bugged”, especially given that pure has been introduced exactly with elemental and do concurrent in mind, I think this would really be a case where you want to amend it, no matter how breaking. Is there really a point in assuring backwards compatibility with something that is broken? What’s the advantage? So, in that (remote I believe) case, I would prefer an amend of the meaning of pure (and probably the pruning of simple, as redundant) instead of changing the requirements of elemental and do concurrent.
In the other case maybe a (backwards compatibile) rewording of the matter might be advisable. But I’m not sure it’s possible, mainly because of this:
I mean, apparently all the additional requirements of do concurrent amount that a “true non simple” call cannot happen, but the case when you read globals that are untouched in the body, albeit factually “simple” would not be allowed if the standard is reworded to require the called procedures to be annotated as simple. Right?
One curiosity:
@certik what does gfortran say if you annotate the locality of A? With either local or shared… there’s a way to make the compiler stop you from falling in the trap? I would really like to, I don’t like the situations where the user has the whole burden of standard compliance, meaning that an error in the code leads to undefined behavior, instead of an informative error. Of course this should be allowed, for performance, in release mode, but I think we need a safe mode where we are sure we get errors for every non legal move.