Meaning of the intent for pointer dummy arguments

1

Dear all,

I thought, that the intent attribute for a pointer only restricts, whether the association status of the pointer can be changed within the procedure. However, two compilers (Intel, GNU) refuse to compile the code below, while NAG is fine with it. Can any of the standard experts say, whether the code is complying?

module test
  implicit none

contains

  subroutine change_pointer_target(ptr)
    ! NOTE: the pointer association is not changed, only its target
    real, pointer, intent(in) :: ptr(:)

    call random_number(ptr)
    ptr(:) = ptr + 1.0

  end subroutine change_pointer_target

end module test

[EDIT: Iā€™ve stripped away some superfluous parts of the demonstration code]

2 Likes
2

Is it not an issue of changing the rank?

3

No, the failing compilers already fail to compile the module itself, before even looking at the program part. I have removed now the program part, which was superfluous for the demonstrationā€¦

4

Well, it always helps to test that a compiler has not merely read and nodded at the source but has actually understood the meaning and will perform the expected calculations.

5

The one, which compiles the code, executes it also correctly as far as I can tell. The question is, however, whether it is that one compiler which is standard complying, or the two others, which refuse compilation. I intuitively would think, that the code is complying with the standard, so compilers should access, but maybe someone knows (or can find it much faster), which part of the standard covers this.

6

(J3/18-007r1) 8.5.10 (2) ā€œINTENT attributeā€

The INTENT (IN) attribute for a pointer dummy argument specifies that during the invocation and execution of the procedure its association shall not be changed except that it may become undefined if the target is deallocated other than through the pointer (19.5.2.5).

As far as I can see, only the target is referenced in the two executable statements.

7

I reckon itā€™s a compiler bug and if interested, OP can file support requests with the compiler implementors.

It appears the two compilers in question have somehow ā€œspecial-casedā€ the intrinsic RANDOM_NUMBER and go beyond what the standard states regarding it:

image
image819Ɨ146 23.1 KB

module m
contains
   subroutine s1(a)
      real, pointer, intent(in) :: a
      !call s2(a)           !<-- Ok with Intel and gfortran 
      call random_number(a) !<-- but not this
   end subroutine 
   subroutine s2(x)
      real, intent(out) :: x
      x = 0.0
   end subroutine 
end module

C:\Temp>gfortran -c a.f90
a.f90:10:23:

10 | call random_number(ptr)
| 1
Error: ā€˜harvestā€™ argument of ā€˜random_numberā€™ intrinsic at (1) cannot be INTENT(IN)

1 Like
9

It might also be useful to see if the Intel Classic is doing the same as the LLVM-based version, but I am not in a position to try this, this evening.

10

Thanks a lot for all the comments. @kargl If thatā€™s the checked in fix for GNU Fortran, thousand thanks for this very quick fix! @FortranFan Iā€™ve now reported it to Intel, I just wanted to be sure, that it is indeed a bug. Actually, I reported a slightly modified version of your example, as that shows it even cleaner than my original one. @NormanKirkby Yes, the classic compiler (also) fails to compile it.

1 Like
12

No problem, Iā€™ve posted it now, thanks.

13

FWIW, your module compiles fine with the Cray compiler. INTENT specified for a pointer argument does, as you suspected, apply to the pointer association status of the argument and has no effect on the target. There is a proposal for a future revision to add a new INTENT-like attribute that would apply to the target, but it turns out to be non-trivial.

14

This is not a simple issue. fpt has, internally, the intents:

Label argument
Function argument
Subroutine argument
Data in
Data inout
Data out
Attributes in
Attributes inout
Attributes out

If you are tracking units and dimensions across a code you need this complexity. I think that there should be a way for the language to express this.

John

1 Like