(j3.2006) paper 13-228

Malcolm Cohen malcolm
Wed Feb 6 19:44:56 EST 2013


On 2/5/13 6:45 PM, Malcolm Cohen wrote:
> Bill Long wrote:
>> I'm not convinced the first alternate edit is correct.  If the dummy
>> argument associated with the pointer function reference is never
>> referenced in the procedure, the procedure appears to be still
>> conforming.
>
> Not so.  Any modification to an entity associated with a dummy argument that
> does not have the TARGET or POINTER attribute is required to go through the
> dummy argument.

Bill Long replies:
>The entity in question does have the TARGET attribute.

Oh for goodness sake.  Any modification to an entity associated with A DUMMY 
ARGUMENT THAT DOES NOT HAVE THE TARGET OR POINTER ATTRIBUTE is required to go 
through the dummy argument.

Look;

Subroutine test(a,b)
  Integer,Intent(InOut) :: a
  Integer,Intent(In) :: b

No TARGET attribute in sight.

> But I was just
>pointing out that there are ways to write a standard-conforming program
>that has an actual argument of a pointer function reference, and yet be
>labeled as non-conforming by the wording of the edit.  That's what I
>meant by saying the edit is "not ... correct".
>
>Note that the example for Q1 has two problems.  It appears to violate
>the anti-aliasing rules for dummy arguments.

Right, under F2008 but not any previous standard.

>  But also, it violates the
>rules for an INTENT(IN) dummy argument, since execution of the
>subroutine causes the non-pointer INTENT(IN) dummy argument to become
>defined.

It doesn't really matter how many rules it breaks in F2008, the point is that it 
does break the rules.

But I will remove the INTENT attributes to avoid confusion.

>   In the interp discussion it might be helpful to explain why
>the example code is not conforming.

You are right, I will point the reader at 12.5.2.13.

I wrote:
> You seem to be thinking it is being modified through that dummy argument, 
> which
> was not the intent of my wording "target of the pointer result is modified". 
> I
> meant that to imply that it was being modified "other than through that dummy
> argument".

Bill replies:
>The extra words are definitely needed.   I think that fixes the problem
>for the intro part of the standard. (If we opt for the alternate
>answer/edits.)

I am perfectly happy to put those back in (thrice).

I went on to mention:
> There is a "third way", but I thought it even worse so didn't bother to write 
> it
> up and make edits.  Viz, having a pointer function reference denote a variable
> only where these problems cannot arise.  But that would not only be a horrible
> inconsistency, but one of the prime places for wanting a pointer function
> reference to denote a variable was as an actual argument, so I thought that
> would be even less popular than the other possible solutions...

Bill opines:
>And yet something that we might consider.

I don't think so.  Too inconsistent, loss of functionality, hideously 
complicated edits.  Plus as Van points out, many processors get the F90-2003 
semantics wrong for actual arguments anyway; if we're going to do this at all, 
we might as well do it consistently.

>The idea of being able to write
>
>   f(x) = expr
>
>does have its attraction, and compilers have gone to the effort to make
>that work.  I don't have good data on how many user codes employ this.

At this point in time, a set of measure zero.

A revision of the paper is forthcoming...

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




More information about the J3 mailing list