https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92122
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> --- Regarding the discussion of comment 0, see: https://mailman.j3-fortran.org/pipermail/j3/2019-October/011691.html https://mailman.j3-fortran.org/pipermail/j3/2019-October/011692.html "So, the whole argument here seems to hinge on the fact that x%q is not a “named variable”. Since if it were, it would have to be a coarray. Also, the LOCK statement in the example is only locking a local lock. Which is very peculiar, but apparently allowed." and: "Yes. I don’t think that local-locking is particularly peculiar; the lock is, after all, accessible to other images because the pointer is associated with a coarray. I understand, and agree, that we want to make sure that any lock-variable is going to be accessible to other images, since that’s the whole point of the feature. The existing constraints do achieve that, so philosophically they are fine as is I think. If on the other hand, we didn’t want to allow this, either we would have to make some rule for lock_type and pointer components, or in this case we could make it “useless” by requiring the lock-variable to be a coarray or coindexed." + "Oh, and I think similar analysis applies to events," → Hence, unless something changes ("if … we didn't want this"), it is valid.
