- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following code sample, that I came across in an older code, doesn't compile with both ifx and ifort, although it does with both Gfortran 11 and (classic) Flang.
module fails
implicit none
type, abstract :: dtype
procedure(dummy_sub), nopass, pointer :: ptr => null()
end type dtype
abstract interface
subroutine dummy_sub( )
end subroutine dummy_sub
end interface
contains
subroutine dummy( )
return
end subroutine dummy
function check(obj) result(n)
class(dtype), intent(in) :: obj
integer(4) :: n
if ( associated(obj%ptr, dummy) ) then
n = 1
else
stop 'Pointer not associated!'
end if
end function check
end module fails
The error message from ifx (and ifort) is the following:
fails.f90(23): error #6424: This name has already been used as an external subroutine name. [DUMMY]
if ( associated(obj%ptr, dummy) ) then
-------------------------------^
fails.f90(23): error #8191: The procedure target must be a procedure or a procedure pointer. [ASSOCIATED]
if ( associated(obj%ptr, dummy) ) then
-------------------------------^
compilation aborted for fails.f90 (code 1)
The error message is rather unclear ("dummy" is a module procedure, not an external one). It's not clear to me why "dummy" isn't allowed to appear as a target in the "associated" intrinsic function. As far as I can tell, even ifort versions of several years ago won't compile the above code sample.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For whatever it's worth, my take is Intel Fortran is in the wrong here to raise errors while the code conforms to the standard.
@GreenScreen , if you have a support subscription with Intel, please submit a service request at the Intel Online Service Center (OSC). Otherwise, you can wait for someone from the Intel team to review this thread and for them to submit a request for you.
Since it may take a while for a resolution to this issue in a future release of the Intel Fortran compilers, you can give the following workaround a try and see if it works in your code (untested as I post this from my child's iPad during vacation):
function check(obj) result(n)
class(dtype), intent(in) :: obj
integer(4) :: n
procedure(dummy_sub), pointer :: lptr !<-- employ a local object as workaround
lptr => obj%ptr
if ( associated(lptr, dummy) ) then
n = 1
else
stop 'Pointer not associated!'
end if
end function check
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@FortranFan, Thanks for your reply.
Unfortunately, I don't have a support subscription, so I hope someone from Intel can take care of submitting a service request, so that we can ultimately get a bug fix for that.
Not that I'd personally recommend the use of procedure pointers, but there are codes out there that use them. Trying to compile the particular code that I've mentioned above, I've already hit this particular bug multiple times, so trying to work around it is tedious.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: "Not that I'd personally recommend the use of procedure pointers," you will note procedure pointers are quite useful for developing flexible libraries that can work with consumer-supplied methods for certain tasks on hand. As such they can prove safer than the use of the `EXTERNAL` statement with codes based in FORTRAN 77 and related but nonstandard dialects. And there are quite a few long running codes out there with EXTERNAL indicating both the need for and utility of this. Thus the procedure pointer facility in the language and robust, reliable implementations in compilers such as Intel Fortran are only par for the course.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We do accept bug reports here on this Forum.
I'll get a bug opened on this one. It is one we'd like to fix soon.
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bug ID CMPLRLLVM-43122
- 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
Though somewhat belatedly, thank you for this fix!
I can confirm that the problem is no longer present in the 2025.0.4 release of ifx (that I've just installed).

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