Problem with pointer under Fortran Compiler XE 14.0.0.103 [Intel(R) 64]

[Krzysztof_P_]

This example has been working for years with all previous 64-bit Intel compiler versions.  Unfortunately with version 14 it fails.

      subroutine bug_intel

      include 'nodecl.inc'

      integer*8 :: k,handle_s1

      type jaja

        integer*4 :: a

        integer*4 :: b

        integer*4 :: c

      end type jaja

      type (jaja),pointer :: s1

      type (jaja),pointer :: s2

      type (jaja),target  :: ss

      integer*4 :: check

      pointer (d,ss)

      allocate (s1)

      s1 % a = 1

      s1 % b = 2

      s1 % c = 3      

      handle_s1 = loc(s1)

      d  = handle_s1

      s2 => ss ! here s2 is wrong

      check = s2 % a      

      end 

Any idea what is wrong? Thank you.

[mecej4]

First idea: you did not provide the contents of 'nodecl.inc'.

[Krzysztof_P_]

'nodecl.inc' contains 

      implicit none

[mecej4]

I get no errors from compiling with the 15.0.2 64-bit compiler. 

I note that the code violates some constraints on integer pointers (sometimes called Cray pointers):

• If a pointee is of derived type, it must be of sequence type
• A pointee cannot have the AUTOMATIC attribute

[JVanB]

The AUTOMATIC attribute, I think, refers to an ifort extension where you can declare a variable to be of AUTOMATIC storage class either in a type specification statement or via an AUTOMATIC statement. Since a pointee has no backing store it is perforce an automatic data object.

But also the Intel docs say that a pointee can't be an automatic object, which I suppose means an explicit-shape array with bounds which are not all constant expressions or a character variable whose LEN is not a constant expression. But at the same time it says that an adjustable array can be a pointee, but isn't that exactly an array with non-constant bounds? Just an example:

subroutine S(m,n)
   implicit none
   integer m,n
   real, allocatable :: R(:,:)
   real P(m,n)
   pointer (C,P)
   integer i,j

   allocate(R(m,n))
   do i = 1,m
      do j = 1,n
         R(i,j) = 10*i+j
      end do
   end do
   m = 1
   n = 1
   C = loc(R(1,1))
   do i = 1,size(P,1)
      write(*,'(*(f4.1:1x))') P(i,:)
   end do
end subroutine S

module M1
   implicit none
   interface F
      function F1(x)
         implicit none
         real F1
         real, intent(in) :: x
      end function F1
      function F2(x)
         implicit none
         double precision F2
         double precision, intent(in) :: x
      end function F2
   end interface F
   pointer (P1,F1)
   pointer (P2,F2)
end module M1

module M2
   implicit none
   contains
      function G1(x)
         real G1
         real, intent(in) :: x
         G1 = 3*x
      end function G1
      function G2(x)
         double precision G2
         double precision, intent(in) :: x
         G2 = x**3
      end function G2
end module M2

program P
   use M1
   use M2
   implicit none
   integer m,n
   m = 2
   n = 3
   call S(m,n)
   P1 = loc(G1)
   P2 = loc(G2)
   write(*,*) F(5.0)
   write(*,*) F(5.0d0)
end program P

Runs as expected with both ifort and gfortran, output is:

11.0 12.0 13.0
21.0 22.0 23.0
   15.00000
   125.000000000000

[IanH]

Repeat Offender wrote:
But also the Intel docs say that a pointee can't be an automatic object, which I suppose means an explicit-shape array with bounds which are not all constant expressions or a character variable whose LEN is not a constant expression. But at the same time it says that an adjustable array can be a pointee, but isn't that exactly an array with non-constant bounds?

Automatic objects (current standard term) excludes dummy objects.  Adjustable arrays (F77 term) are always dummy objects.  Never the twain shall meet.

[JVanB]

You're reading the wrong standard. Look at ifort's page on cray pointers, where it says:

"A pointee array can have fixed, adjustable, or assumed dimensions."

Having read that section, please re-read Quote #5 in that context.

[IanH]

I don't follow your point.  What do you think is the issue with the documentation?

Your example has an automatic object as the pointee...  are you saying that the documentation is inaccurate because that [apparently] works?

[JVanB]

Yeah, that's about the gist of it. The page https://software.intel.com/en-us/node/512030 says: "A pointee cannot be ... An automatic object". That contradicts the statement above that "A pointee array can have fixed, adjustable, or assumed dimensions." The program above tests which of the cacaphony of contradictory voices is valid, and it seems to me that the adjustable, i.e. non-constant, dimensions statement is correct. Also assumed dimensions means assumed size, not assumed shape, but that should be obvious because a cray pointer doesn't carry enough baggage around with it to point at assumed shape (not to mention assumed length) objects.

For evidence that the page can be misleading, see Quote #4 above. Also if non-SEQUENCE types are invalid pointees, how are we supposed to ask the compiler to check, perhaps /stand:f08?

[IanH]

Repeat Offender wrote:

Yeah, that's about the gist of it. The page https://software.intel.com/en-us/node/512030 says: "A pointee cannot be ... An automatic object". That contradicts the statement above that "A pointee array can have fixed, adjustable, or assumed dimensions."

The "supposed" definitions of automatic object and adjustable dimension in the second paragraph of #5 are incomplete.

Per the ifort documentation (or previous language standard terminology) - adjustable has a particular meaning beyond "not constant" - adjustable dimensions are only relevant to the dimensions of dummy objects.  Your test program doesn't have any array dummy arguments, hence no adjustable arrays, hence it doesn't have any adjustable dimensions. 

Similarly, assumed dimensions are only relevant to dummy objects.

Per the ifort documentation (or current language standard terminology, which as a user I would hope would be consistent) - only local variables can be automatic objects.  Dummy objects are not considered local variables (the name is local, but the data object associated with the name is not - see also the terminology in the current standard).

A local (non-dummy) array with fixed (constant) dimensions, but with length parameters that are determined by a non-constant specification expression would be considered an automatic object.  But I don't see any contradiction there - .different aspects are being discussed - you need to satisfy both.

I have no idea what the design intent is here, but the general principle that violations of the restrictions on the program may not be diagnosed by the compiler may be relevant - along with the general principle that violations.of the restrictions on the program may not result in obviously erroneous runtime behaviour.  There's also the third general principle that the documentation might be wrong.

[Krzysztof_P_]

I would like to thank all for the discussion and helpful hints. In order to explain what is the idea behind this example I want to say that I tried to have a kind of a void pointer like in C++. I must say that all that business with pointers in Fortran is little awkward. Suppose that I change this simple example as shown below and it will work with Intel compiler 2015.. The difficulty is to delete allocated space outside this function (to avoid memory leaks) having the handle to the object only (this is my goal). I can do this easily by calling this function (obviously some modifications are needed) twice while s1 is a static object. Anyway thanks for the help. I must say that I am not too happy that compiler does not warn the user in such circumstances. Just to remind you, the execution of this little code was successful till Intel 2013 (since last 6 years at least ...) without any warning.

      subroutine bug_intel
      implicit none

      integer*8 :: k,handle_s1
      type jaja
        sequence
        integer*4 :: a
        integer*4 :: b
        integer*4 :: c
      end type jaja
      type (jaja),pointer :: s1 (:)
      type (jaja),pointer :: s2 (:)
      type (jaja),target  :: ss (1)
      integer*4 :: check
      pointer (d,ss)
      save s1,s2

      allocate (s1(1))
      s1 % a = 1
      s1 % b = 2
      s1 % c = 3      
      handle_s1 = loc(s1)

      d  = handle_s1
      s2 => ss

      end 

[JVanB]

@ IanH: If we take the ifort documentation to be the Digital Fortran Language Reference Manual (Digital Equipment Corporation, Maynard Massachusetts 1997 [of fond memory]) p. B-9 we see the quotes "A pointee array can have fixed, adjustable, or assumed dimensions." "A pointee ... cannot have the following attributes: ... AUTOMATIC ..."  "A pointee cannot be: ... An automatic object ..." and my guess would be that all that stuff goes back even farther.

As I said, I am only quoting the above document as retained in the ifort page I linked to back in Quote #9. Maybe you could rewrite it if you don't like the way it throws around F77 terminology in an F08 environment. The part about SEQUENCE types seems simply to be wrong.

@ Krzysztof P.: your problem seems to be a regression in version 14, fixed in the latest version. If you are able to upgrade, everything might just work with no need for further intervention on your part.

[mecej4]

In fact, it may be by looking up the Digital manuals that we can trace the origins of the attribute AUTOMATIC that may have caused some doubts in this thread. By default, DF/CVF allocated local variables statically and their values would be preserved. The compiler had an option, /automatic, to cause local variables to be allocated on the stack. The option applied to all the routines in the source file that got compiled with that option. For finer control, they had the AUTOMATIC declaration statement, which applied like any other type declaration to the variables list that followed.

[Steven_L_Intel1]

Indeed, AUTOMATIC is an extension that predates "automatic" variables in Fortran, which came about in Fortran 90. In In DEC Fortran, the default for local variables was static allocation, so we added AUTOMATIC as a way of informing the compiler you didn't want local variables allocated statically. "Automatic variables", in the Fortran 90 standard sense means a local variable whose allocation is of variable size and based on a dummy argument, COMMON, module or host-associated variable.