(j3.2006) Is this allowed?

[Malcolm Cohen]

>This is prohibited by C558:
>
>  subroutine S1 ( A )
>    integer, value, volatile :: A

Yes.

>This, which is more wordy than S1 but identical in functionality, is
>allowed:
>
>  subroutine S2 ( A )
>    integer, intent(in) :: A

Not seeing the connection here, the interface of S2 differs from that of S1. 
VALUE and VOLATILE both affect the interface.

>Is this allowed?
>
>  subroutine S3 ( A )
>    integer, value :: A
>    block
>      volatile :: A

No, clear violation of C558.

>The VOLATILE attribute in S3 appears to be prohibited in C558, but the

It does indeed.

>only processor I have that understands the BLOCK construct says nothing.

Compiler behaviour is not particularly relevant here.

>VALUE is not mentioned in 5.3.19 (especially not in C559).  5.3.19p2
>says
>
>        Within a BLOCK construct, a noncoarray object may have the
>        VOLATILE attribute even if it does not have the attribute
>        outside the BLOCK construct.
>
>The word "may" explicitly confers permission for the VOLATILE attribute.
>There's nothing in this sentence about the object not having the VALUE
>attribute.  Does this contradict C558, or does A no longer have the
>VALUE attribute within the BLOCK construct (and where does it say
>that!)?

Obviously A has the VALUE attribute throughout.  However, the quoted sentence 
does not say that it overrides other requirements.  For example

   REAL,PARAMETER :: zero = 0
   BLOCK
      VOLATILE zero

the entity ZERO is not a variable (but is a data object), and does not have the 
VOLATILE attribute outside the BLOCK, but still falls foul of C559 because it is 
not a variable.

Similarly, the same applies for INTENT(IN) as for VALUE, again the constraint 
violated is C559.

>8.1.4p2 says
>
>        The appearance of the name of an object that is not a construct
>        entity in an ASYNCHRONOUS or VOLATILE statement in a BLOCK
>        construct specifies that the object has the attribute within the
>        construct even if it does not have the attribute outside the
>        construct.
>
>Again, there's no exception if the object has the VALUE attribute.

And there is no exception if it is not a variable either, this is not giving 
permission, and it does not say other requirements do not hold.  It just gives 
the semantics for when an ASYNCHRONOUS or VOLATILE statement appears in such a 
context.

I will note that this one does not even say "noncoarray object", but again, this 
sentence is not taking away any of the requirements to have a valid ASYNCHRONOUS 
or VOLATILE statement.  It just says what it means.

>Within the BLOCK construct, does A still have the VALUE attribute?

Yes.

>  I couldn't find any text that makes it go away.

Well yes, and there is text saying it does have the VALUE attribute, so...

>How about this one?
>
>  subroutine S4 ( A )
>    integer, value :: A
>    call T
>  contains
>    subroutine T
>      volatile :: A

Still violates C558, and playing this host association trick with an INTENT(IN) 
variable still violates C559, and playing this or the use association trick with 
a named constant still violates C559.

>Two of my processors are perfectly happy with it, but one complains.

The one complaining appears to have it right.

>16.5.1.4p1 says "... a noncoarray local entity may have the VOLATILE
>attribute even if the host entity does not."  Again, "may" explicitly
>confers permission, and there's no exception if the object has the VALUE
>attribute.  Does this contradict C558, or does A no longer have the
>VALUE attribute within the internal subroutine (and where does it say
>that!)?

No and no.

>If S3 and S4 are allowed but S1 isn't, did we really intend this
>inconsistency?

S3 and S4 clearly violate C558.

>If we didn't intend these to be inconsistent

They do not appear to be inconsistent...

>, do we remove VOLATILE from
>C558, add "without the VALUE attribute" in 5.3.19p2, 8.1.4p2, and
>16.5.1.4p1, or do nothing?

... so that would be a "do nothing" (for the standard) and a "raise a bug 
report" (for the compilers that don't complain).

>If we intended these to be inconsistent, should we prefix "Within the
>scoping unit where it is declared" to C558, so as not to be contradicted
>in 5.3.19p2, 8.1.4p2, and 16.5.1.4p1?

It is not compulsory to read those sentences are contradictory, and C558 is not 
the only applicable constraint.  When there are two readings of a sentence, and 
only one leads to a contradiction, the meaning of the sentence can only be the 
noncontradictory one.

I will go along with "these things are confusing", and that's because the whole 
idea of having sub-scoped attributes is confusing: I would much rather we had 
not done VOLATILE (and ASYNCHRONOUS) this way, but that's water that has long 
since flowed under the bridge.  8.1.4p2 does not even use "may", so there cannot 
be any confusion or contradiction there.

It would, I think, be a good idea to reword 5.3.19p2 and 16.5.1.4p1 to avoid 
"may" as that can lead to a contradictory misreading.  It might not be an 
improvement of exposition though.

Finally, one might imagine that, unlike INTENT(IN), it would not be unreasonable 
for VALUE to allow an inner VOLATILE or ASYNCHRONOUS because (a) the variable is 
permitted to be updated, and (b) an inner VOLATILE or ASYNCHRONOUS would not 
affect the interface of the procedure.  However, I think this would be a 
confusing way to write the program: people who want an inner VOLATILE variable 
can just have an INTENT(IN) argument and take a copy of it (as per your S2 - it 
is crystal clear what is going on there).

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.