Problem with C_F_STRPOINTER

[Robert_van_Amerongen]

This subroutine is new in the latest compiler version. I use the second version, 

C_F_STRPOINTER(cstrptr, fstrptr, nchars)

that is, it take a pointer to a null-teminated string (cstrptr) and retuns a character string (fstrptr).

I expect that, after completion, the call ASSOCIATED( fstrptr) retuns .TRUE., but I get .FALSE.

I have added a small example.

In the project where I met this problems a subsequent use of fstrptr failed as the system complained that fstrptr was not associated. Surprisingly, I was not able to get the same result in the attached example. 

In any case I presume that something get wrong.

Robert

[andrew_4619]

ooo! That must be a new f2023 thing? Looks useful.

[FortranFan]

@Robert_van_Amerongen ,

In your actual code, you can test using the option in the example below and see if it works out.  If yes, that points further to something being in Intel Fortran team's implementation of this Fortran 2023 feature.

Intel Support team,

Please look at the example below, a variant of OP's reproducer.  Perhaps this will help the Intel Fortran team investigate this issue further?

  MODULE testcfstr_mod
  IMPLICIT none (external, type)
  PRIVATE
!
  ABSTRACT INTERFACE
    INTEGER(KIND=C_INT) FUNCTION strlen_z(ptr) BIND(C)
    USE ISO_C_BINDING, ONLY : C_INT, C_PTR
    TYPE(C_PTR),VALUE :: ptr
    END FUNCTION strlen_z
  END INTERFACE
  PROCEDURE(strlen_z),PUBLIC, BIND(C, NAME='strlen') :: strlen
!
  END MODULE testcfstr_mod
!
  PROGRAM testcfstr
  USE ISO_C_BINDING, ONLY   : C_PTR, C_LOC, IFX_C_F_STRPOINTER => C_F_STRPOINTER, F_C_STRING, C_ASSOCIATED, c_f_pointer
  USE ISO_FORTRAN_ENV, ONLY : COMPILER_VERSION
  USE testcfstr_mod, ONLY   : strlen
  IMPLICIT none (external, type)

  CHARACTER(LEN=9),TARGET  :: string_in
  CHARACTER(LEN=:),POINTER :: string_out
  TYPE(C_PTR)              :: pString
  INTEGER                  :: length
  INTEGER                  :: iPos
!
  write(*,*) 'Compiler version: ', COMPILER_VERSION()
!
  string_in = F_C_STRING("abcdefgh")
  pString = C_LOC(string_in)
  write(*,*) 'c_associated: ', C_ASSOCIATED(pString)
  length = strlen(pString)
  write(*,*) 'length:', length
  !CALL IFX_C_F_STRPOINTER(pString, string_out, length)  !<-- A
  CALL C_F_STRPOINTER(pString, string_out, length)     !<-- B
  write(*,*) 'associated: ', ASSOCIATED(string_out)     !  <<<<<<<<<<<<<<<<<<<<<<<  wrong?
  write(*,*) 'string out: ', string_out//"<<"           ! works fine here, but fails elsewhere
  iPos = INDEX(string_out, "bc")                        ! works fine here, but fails elsewhere
  write(*,*)'ipos', ipos

!
  STOP
contains
   subroutine c_f_strpointer( cstrptr, fstrptr, nchars )
      ! Argument list
      type(c_ptr), intent(in)   :: cstrptr
      character(len=:), pointer :: fstrptr
      integer, intent(in)       :: nchars
      ! Associate the pointer
      block
         character(len=nchars), pointer :: t
         call c_f_pointer( cstrptr, t )
         fstrptr => t
         t => null()
      end block
   end subroutine

  END PROGRAM testcfstr

* See the program output below using IFX and notice the "T" with the associated check.  Now you can rerun with line marked A uncommented and the subsequent line marked B commented out to reconfirm the issue posted by OP.

C:\Temp>ifx /standard-semantics testcfstr.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.1.0 Build 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32537.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:testcfstr.exe
-subsystem:console
testcfstr.obj

C:\Temp>testcfstr.exe
 Compiler version:
 Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024
 .1.0 Build 20240308
 c_associated:  T
 length: 8
 associated:  T
 string out: abcdefgh<<
 ipos 2

[Ron_Green]

I am not sure this is a bug in c_f_strpointer. I sent this to our front-end team first. I think the call to associated(string_out) is flawed. As we see, the string is fine, and INDEX works with it. Something in the argument passing to associated perhaps.

the bug ID ix CMPLRLLVM-57671

[FortranFan]

@Ron_Green  wrote:

I am not sure this is a bug in c_f_strpointer ..

---

@Ron_Green ,

Re: "I am not sure this is a bug in c_f_strpointer," when can an Intel Fortran customer expect the implementation of ASSOCIATED intrinsic per Fortran standard in Intel Fortran to return true/false with respect to the association status of an object with a POINTER attribute?

Consider the example below, why would an Intel Fortran customer receive the association status as TRUE with an equivalent subprogram whereas the implementation per the compiler returns FALSE?

   use, intrinsic :: iso_c_binding, only : c_ptr, c_loc, c_f_strpointer, c_f_pointer
   character(len=:), allocatable, target :: s
   character(len=:), pointer :: ps
   type(c_ptr) :: cp
   ps => null()
   print *, "Is associated(ps)? ", associated(ps), "; expected is F"
   s = "Hello World!"
   cp = c_loc( s )
   call my_c_f_strpointer( cstrptr=cp, fstrptr=ps, nchars=len(s) )
   print *, "Following my_c_f_strpointer invocation, is associated(ps)? ", associated(ps), "; expected is T"
   ps => null()
   call c_f_strpointer( cstrptr=cp, fstrptr=ps, nchars=len(s) )
   print *, "Following c_f_strpointer invocation, is associated(ps)? ", associated(ps), "; expected is T"
contains
   subroutine my_c_f_strpointer( cstrptr, fstrptr, nchars )
      ! Argument list
      type(c_ptr), intent(in)   :: cstrptr
      character(len=:), pointer :: fstrptr
      integer, intent(in)       :: nchars
      ! Associate the pointer
      block
         character(len=nchars), pointer :: t
         call c_f_pointer( cstrptr, t )
         fstrptr => t
         t => null()
      end block
   end subroutine
end

C:\Temp>ifx /free /standard-semantics p.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.1.0 Build 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.36.32537.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\Temp>p.exe
 Is associated(ps)?  F ; expected is F
 Following my_c_f_strpointer invocation, is associated(ps)?  T ; expected is T
 Following c_f_strpointer invocation, is associated(ps)?  F ; expected is T

[Ron_Green]

the FRTL developer is investigating, as is our Fortran parsing team.

[Robert_van_Amerongen]

Thank to you all.

Andrew: you are right. This is a nice new feature. The standard 2023 has lots of them. See "The new features of Fortran 2023" by John Reid (N2212.pdf (wg5-fortran.org)). Or the 2023 edition of Modern Fortran explained, esp. chapters 22 and 23.

Fortran fan: thanks for your explanation. Some time ago I wrote some functions that has the same functionality  as the new added functions . The C_F_STRPOINTER gave problems at that time, see my post ("Bug with IFX") of January 5, 2023. In a later release the bug was removed and my function worked well. Now I want to replace my function with Intel's one, it again shows incorrect behaviour.

Ron, I'll wait your findings. In the mean time I use my own version .

Robert

[FortranFan]

@Ron_Green  wrote:

the FRTL developer is investigating, as is our Fortran parsing team.

---

@Ron_Green ,

Thanks.

My question to you was more out of curiosity as to why you thought there was not a compiler bug here.

[Ron_Green]

I always thought this was a bug.  But I confused the matter, I'm afraid.  

My comments were thoughts about whether the bug was in the Fortran Runtime Library (FRTL) or our compiler's front end.  For intrinsics, the two have to cooperate.  The Runtime Library has the function that actually implements c_f_strpointer.  However, the functions in the FRTL have to be called.  The call and return has to be created from compiler front end while it parses your code.  In a case like this, the error could be in the FRTL function.  OR it could be that the call or return were incorrect, hence the front end.

I knew this was a bug, I just did not know which compiler component was, or is, at fault.  So 2 teams are looking at it.