- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ooo! That must be a new f2023 thing? Looks useful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Ron_Green wrote:I am not sure this is a bug in c_f_strpointer ..
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the FRTL developer is investigating, as is our Fortran parsing team.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Ron_Green wrote:the FRTL developer is investigating, as is our Fortran parsing team.
Thanks.
My question to you was more out of curiosity as to why you thought there was not a compiler bug here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This issue has been fixed in the recently released Intel Fortran Compiler, available for download as part of Intel HPC Toolkit 2024.2.1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Devorah, I can confirm that it works now as espected.
Thanks for your help and for letting me know.
Robert

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page