Automatic pointer targeting

[YG]

Hello,

As common in OO programming, an object "y" of derived type "t" should have access to some other data "x", and we grant them access by storing a local pointer "ptr" to such data.  Such pointer needs only exist inside the object "y", while in the main program we declare "x" as "target".

Often enough, we want to handle the pointer association "y%ptr => x" through a dedicated subroutine that performs additional operations and consistency checks.  With F2003, our only option is to have a "target" dummy argument that corresponds to the actual argument "x", but this way the compiler does not perform any check to verify that "x" was indeed a "target".  I think that this may lead to undefined behaviour in certain situations where "x" was not declared as target and gets copied-in instead of being passed by reference.  Please correct me if I am wrong.

The F2008 standard helps us here, as we could now use the "automatic pointer targeting" feature, and declare a "pointer" dummy argument with "intent(in)".  This forces the actual argument "x" to be either a "pointer" or a "target".  Unfortunately, it appears that such a useful feature is not yet implemented by the Intel Fortran Compiler, while GFortran supports it since version 4.6.  Please consider the following code:

program p

  implicit none

  type :: t
    real, pointer :: ptr(:) => null()
  end type t

  real, target :: x(10) = 1.0
  type( t )    :: y

  ! This produces an error at compile time with ifort
  call attach_pointer( x,y )

  ! This produces the right result in gfortran
  write(*,*) y%ptr

contains

  subroutine attach_pointer( from, to )
    real, pointer, intent( in    ) :: from(:)
    type( t ),     intent( inout ) :: to
    to%ptr => from
  end subroutine attach_pointer

end program p

Compiling with

$ ifort -stand f08 p.f90 -o -p

I see a compiler error:

p.f90(13): error #6691: A pointer dummy argument may only be argument associated with a pointer.  
  call attach_pointer( x,y )
-----------------------^
compilation aborted for p.f90 (code 1)

I am working on a project that must be supported by gfortran and ifort both, and we would like to use "automatic pointer targeting" for the reasons above.  Is there any chance it will be included in the next ifort release?  In the meanwhile, is there a workaround I should be aware of?  Or possibly, are we overestimating the importance of such a feature instead?

$ ifort -V

Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.164 Build 20150121

Thanks,

Yaman

[pbkenned1]

Hello Yaman,

Thank you for submitting the issue.  I'll check with the developers regarding the status of this 'feature'.  Indeed it does work fine with gfortran.  I checked a development version of ifort 16.0 (unreleased), and see the same problem.

Patrick

[pbkenned1]

This might be a workaround for you.  Change:

 real, pointer, intent( in    ) :: from(:)

to:

 real, target, intent( in    ) :: from(:)

[U544610]$ diff U544610.f90 U544610-mod.f90
21c21
<     real, pointer, intent( in    ) :: from(:)
---
>     real, target, intent( in    ) :: from(:)

[U544610]$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.164 Build 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

[U544610]$ ifort U544610-mod.f90 -stand f08 && ./a.out
   1.000000       1.000000       1.000000       1.000000       1.000000
   1.000000       1.000000       1.000000       1.000000       1.000000
[U544610]$

Patrick

[FortranFan]

Yaman G. wrote:

Hello,

As common in OO programming, an object "y" of derived type "t" should have access to some other data "x", and we grant them access by storing a local pointer "ptr" to such data.  ..

     Or possibly, are we overestimating the importance of such a feature instead?

You better know what you're doing for as you know, this is one of the most complicated aspects of the language!

By the way, I am not really sure of your comment, "common in OO programming, .. we grant them access by storing a local pointer "ptr" to such data".  OO design is what really matters and OO programming is simply an implementation of it.  Most OO designers would typically shun such use of pointers. And surely enough, many strict OO languages (Java for example) disallow pointers altogether.  You may want to rethink your code design.

Separately, for the other situation mentioned where the dummy argument has the TARGET attribute but the actual argument doesn't, I was under the impression the Fortran standard states the pointer should become undefined on return to the calling routine, regardless of the attribute of the actual argument.  I don't know if the contained procedure situation changes this somehow - I doubt it because you can't do y%ptr => x in your program p if x doesn't have the target attribute, so I don't see why you can get around it by calling a contained procedure.  So I wonder if the two compilers you mention may be in error if such a situation is allowed.  I'll leave it to better minds to explore this.

Nonetheless, one can never be sure any compiler is fully correct in these aspects and if any brave soul really wants to make use of these features, then they better understand the standard inside and out and be able to check their code with as many different compilers they can get their hands on, not just one or two!

[FortranFan]

Patrick Kennedy (Intel) wrote:

This might be a workaround for you.  Change:

 real, pointer, intent( in    ) :: from(:)

to:

 real, target, intent( in    ) :: from(:)

[U544610]$ diff U544610.f90 U544610-mod.f90
21c21
<     real, pointer, intent( in    ) :: from(:)
---
>     real, target, intent( in    ) :: from(:)

[U544610]$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.164 Build 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

[U544610]$ ifort U544610-mod.f90 -stand f08 && ./a.out
   1.000000       1.000000       1.000000       1.000000       1.000000
   1.000000       1.000000       1.000000       1.000000       1.000000
[U544610]$

Patrick

Patrick,

See the comments in the original post:

Yaman G. wrote:

..

Often enough, we want to handle the pointer association "y%ptr => x" through a dedicated subroutine that performs additional operations and consistency checks.  With F2003, our only option is to have a "target" dummy argument that corresponds to the actual argument "x", but this way the compiler does not perform any check to verify that "x" was indeed a "target".  I think that this may lead to undefined behaviour in certain situations where "x" was not declared as target and gets copied-in instead of being passed by reference.

..

 

[pbkenned1]

Thanks for the feedback FortranFan, I glossed over the fact that Yaman's "only option is to have a "target" dummy argument."

I think the only real issue is that we simply have not yet implemented the F'08 feature that actual arguments with the target attribute are allowed to correspond to dummy pointer arguments with intent(in).

I haven't got confirmation from the developers yet whether this is something on their radar or not.  I hope so, for the sake of completeness.

Patrick

[Steven_L_Intel1 · Accepted solution]

This is a F2008 feature we haven't implemented yet, but it's already on our list. The internal tracking ID is DPD200182211.

[pbkenned1]

Thanks Steve.  While I was attaching this thread to DPD200182211, indeed a developer confirmed the same.  Amazing that gfortran apparently picked this up from F'08 way back in version 4.6 (per Yaman).

Patrick

[Steven_L_Intel1]

We initially picked up on the procedure pointer part of this, but not the data part. We've known about it for a few years - it will get done. gfortran works on a different development model than we do - the smaller items they tend to do first, the bigger items sometimes don't get done at all.

[FortranFan]

Patrick Kennedy (Intel) wrote:

...  Amazing that gfortran apparently picked this up from F'08 way back in version 4.6 (per Yaman).

..

Well, isn't this one of several "convenience" features introduced in Fortran 2008?  I've often felt there are some "low hanging fruit" in Fortran 2008 that I wish more compilers, especially Intel, had picked sooner similar to gfortran.  Or perhaps, thinking of how this particular feature might get used, it's best if it's implemented last! :-)

[pbkenned1]

The fact we did this for procedure pointers (way back in the 12.1 compiler) seems more important than doing so for data pointers, the latter is indeed mostly a 'convenience' feature.  But it also allows for actual arguments to be checked for being 'simply contiguous', if the dummy pointer is given the contiguous attribute.  The compiler will be able to improve optimization, for example, no copy in/copy out will be required.

Patrick

[YG]

Thank you all for your feedback!  I am new to this forum, is there a way to keep an eye on the status of DPD200182211?

Yaman

[Steven_L_Intel1]

This would get implemented in a major release and will be mentioned in the release notes when that happens. This thread will also get updated.

[Edmondo_G_]

Dear all,

I would also stress that the dummy pointer could also be polymorphic, like in:

module Test_mod
implicit none
type Tbase
	    real :: a
endtype

type, extends(Tbase) :: Text
    	integer :: i
end type

contains
    subroutine genpoint(vin)
	        		class(Tbase),pointer,intent(in) :: vin
		    end subroutine
end module

program Test
implicit none
use Test_mod
    type(Text),target :: p

    call genpoint(p)

end program 

[FortranFan]

Edmondo G. wrote:

Dear all,

I would also stress that the dummy pointer could also be polymorphic ...

Intel Fortran currently fails to compile the shown code since the F2008 features have not yet been implemented, but gfortran works ok:

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.2.179 [Intel(R) 64]...
test.f90
test.f90(6): error #6633: The type of the actual argument differs from the type of the dummy argument.   

test.f90(6): error #6691: A pointer dummy argument may only be argument associated with a pointer.   

compilation aborted for test.f90 (code 1)