target attribute for dummy, but not actual, argument

[Alexis_R_]

Is it problematic/illegal if a dummy argument has a target attribute, but the corresponding actual argument does not?

I read a quote somewhere that:

"Notice that for this to really work, the actual argument, 'a', must be declared with the target attribute. You correctly declare the dummy argument in the assign_pointer routine with the target attribute, but the actual argument must also have that attribute (otherwise it's illegal for any pointer to be associated with it). Just a minor point..." [emphasis mine]

Is it true that such association is illegal? If so, can I get the compiler to check this the way it checks interfaces for other argument attributes?

Also, what are the consequences, if any, of such association for optimisation?

[Hirchert__Kurt_W · Accepted solution]

If the actual argument has the target attribute, then a pointer assignment done inside the procedure has the possibility of surviving beyond the execution of the procedure. (In a routine named assign_pointer, this is probably what you want, so that's likely why the note says it is required.)

It is legal for the actual argument to not have the target attribute, but if that is the case, pointer assignments with that dummy argument on the RHS are only valid for the duration of the procedure execution. Thereafter, such pointers are considered undefined and thus unusable.

[In reality, the pointer will likely point to the actual argument in either case, but if the target attribute is missing, the optimizer will not allow for the possibility of that pointer being using to reference or define the contents of the actual argument after the procedure execution, so any attempt to use the pointer that way has a good chance of giving you bad results -- thus, the use of the pointer in that case is prohibited.]

-Kurt

[Steven_L_Intel1]

It is legal for the dummy to have TARGET and the actual not to have TARGET. The standard has quite a bit of text on the various combinations and what they mean - p269-270 of F2003.

If a variable does not have the TARGET attribute, whether it is a dummy or not, you're not allowed to point a pointer to it. The compiler will complain about this automatically, for example:

[fortran]subroutine sub (foo)
integer foo
integer, pointer :: bar
bar => foo
end[/fortran]

t.f90(4): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute. [FOO]
bar => foo
-------^

In the post you quote, the original code violated this rule.

[Alexis_R_]

Quoting Steve Lionel (Intel)

In the post you quote, the original code violated this rule.

I am not sure I agree with your understanding of the post in question, but that's not important. Thanks for pointing me to the relevant part of f2003.

Consider the following code:

[fortran]
module assign_pointer_class
	type mytype
	   real, pointer :: pr
	end type mytype
contains
	subroutine assign_pointer(this, a)
		type (mytype), intent(out) :: this
		real, target, intent(in) :: a
		this%pr => a
	end subroutine assign_pointer
end module assign_pointer_class

program main
	use assign_pointer_class
	type (mytype) :: x, y
	 ! THIS IS THE RIGHT WAY
	real, target :: a
	real :: b
	a = 1.23
	b = 2.34
	call assign_pointer(x,a)
	call assign_pointer(y,b)
	print *, associated(x%pr), associated(y%pr)
	print *, x%pr, y%pr
end program main[/fortran]

My understanding of the standard (p.270, l.20-22) is that y%pr should be undefined at line 26.

The output of the ifort 11.1-compiled program is:

[bash] T T
   1.230000       2.340000    [/bash]

Kurt points out that even though the pointer points to the actual argument in both cases (x and y), y%pr may end up giving bad results. I have not seen this in my project yet, even though I have analogous situations. This, together with the fact that ifort does not warn when the actual and dummy arguments do not have matching TARGET attributes, makes me wonder whether ifort actually does keep the pointer associated even when the actual argument does not have the TARGET attribute. Of course, it's possible I've just been lucky so far, in which case I'm just left wondering why ifort does not give such a warning.

Hope this makes sense & I haven't missed anything obvious.

[Steven_L_Intel1]

As I said above, it is not wrong, in isolation, for the actual and dummy not to have matching TARGET attributes.

In your example, when the second call to assign_pointer returns, the association status of y%pr is undefined. That does not mean that ASSOCIATED must return F - it means that you can't depend on ASSOCIATED to return a meaningful value - the same as if you had called ASSOCIATED for an uninitialized pointer.

There isn't anything the compiler can warn you about here. The call itself is legal. The compiler does not know that you have done a pointer assignment in the subroutine so it can't arbitrarily assume that the pointer status is undefined.

[Alexis_R_]

Quoting Steve Lionel (Intel)

There isn't anything the compiler can warn you about here. The call itself is legal. The compiler does not know that you have done a pointer assignment in the subroutine so it can't arbitrarily assume that the pointer status is undefined.

Thanks for the clarifications. I guess I keep thinking that warnings could be used to warn of potentially dangerous coding practice with potentially unpredictable outcomes. Clearly, I understand that the code is legal, otherwise I'd be wondering about error messages. The fact that an actual does not have TARGET but the dummy does could (in my mind) trigger some kind of message at compile time to warn of potentially unpredictable outcome.

I guess I'm only acutely aware that I constantly need saving from myself :)

Thanks again for the informative answers!

[Steven_L_Intel1]

Perhaps this might fit into a class of diagnostics we call "usage". I'll think about this...