Pointer function reference on LHS of assignment statement - broken?

[jackie-san]

Hi everyone,

I've recently learnt the Fortran standard (since F08) supports referencing a function which returns a pointer in variable-definition contexts, such as on the LHS of assignment statements. This is treated as if the target of the pointer is used as the variable. However, the below simple test case fails to compile with the latest ifx/ifort release:

module mod
  implicit none
  integer, target :: x = 1, y = 2, z = 3

contains
  function get(key)
    integer, intent(in) :: key
    integer, pointer :: get

    select case(key)
    case(1)
      get => x
    case(2)
      get => y
    case(3)
      get => z
    end select
  end function get

end module mod

program main
  use mod
  implicit none
	
  get(3) = 100
  write(*,*) get(3)
end program main

This gives the error

error #6404: This name does not have a type, and must have an explicit type.   [GET]
        get(3) = 100
--------^

i.e. it's still expecting get to be declared as a variable. Using gfortran 9.3.0, the code compiles and outputs the expected result (100).

If I use the pointer function reference in other variable-definition contexts, such as in a READ statement or as an actual argument for a dummy argument with intent out/inout, then the code compiles fine and works as expected. It's specifically when the function reference is on the LHS of an assignment statement.

Can anyone confirm whether this is a bug with the compiler or if I'm missing something really simple? Cheers!

[Arjen_Markus]

The code is accepted by gfortran and gives the expected result. I used Intel Fortran oneAPI 2023.1.0 and that gives very similar errors. Commenting out the statement on line 26 makes the error messages go away.  As far as I can tell, this is standard-conforming and it should work. I have used this sort of constructs in the past myself.

[Arjen_Markus]

Even more interestingly:

• I changed the use statement to: use mod, only: get
• Removed the "implicit none" in the main program

The result:

Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.1.0 Build 20230320
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

pointerget.f90(26): error #6072: A dummy argument of a statement function must be a scalar identifier.   [3]
  get(3) = 100
------^
pointerget.f90(27): error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [GET]
  write(*,*) get(3)
-------------^
pointerget.f90(26): remark #7713: This statement function has not been used.   [GET]
  get(3) = 100
--^
compilation aborted for pointerget.f90 (code 1)

Maybe this helps to see what is going wrong in the compiler.

[Ron_Green]

Interesting.  the .mod file has the correct reference for GET.  and if I rewrite this slightly using function result , shown below, it compiles and gets the correct output.  I will write up a bug report.  Thank you for bringing this to us!

module mod
  implicit none
  integer, target :: x = 1, y = 2, z = 3

contains
  function get(key) result(get_res)
    integer, intent(in) :: key
    integer, pointer :: get_res

    select case(key)
    case(1)
      get_res => x
    case(2)
      get_res => y
    case(3)
      get_res => z
    end select
  end function get

end module mod

program main
  use mod
  implicit none
	
  get(3) = 100
  write(*,*) get(3)
end program main

ifx get.f90 -what -V
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.0.0 Build 20231017
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

 Intel(R) Fortran 24.0-1238.2
GNU ld version 2.39-9.fc38
$ ./a.out
         100

[Ron_Green]

I does seem to confuse the function pointer on the LHS as a Statement Function reference. the bug ID is CMPLRLLVM-55125