- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greetings,
I believe I have found a regression in the 2023.0.0 release for both Classic and IFX. Please consider the following code which fails to compile with the error error #7815: Recursive use of symbol in specification expression for type parameter is prohibited. I'm guessing this is due to the recent updates to the compiler front end mentioned in Ron Green's @Ron_Green blog post The Next Chapter for the Intel® Fortran Compiler . Is it possible to fix this in the next point release?
! This doesn't compile with either Ifort or IFX.
!
! Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on
! Intel(R) 64, Version 2021.8.0 Build 20221119_000000
!
! character_error_7815.f90(28): error #7815: Recursive use of symbol in
! specification expression for type parameter is prohibited. [ACHAR]
!
! Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version
! 2023.0.0 Build 20221201
!
! character_error_7815.f90(28): error #7815: Recursive use of symbol in
! specification expression for type parameter is prohibited. [ACHAR]
!
module mymod_m
type mytype_t
character :: achar
end type mytype_t
type(mytype_t) :: my_modvar
end module mymod_m
program variable_declaration_parse
use mymod_m
implicit none
character :: achar*(len(my_modvar%achar))
end program variable_declaration_parse
Thanks,
Dave
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree that the compiler is getting confused by the two different symbols both named achar. The simple workaround is to rename one of them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the nice and small reproducer!
It looks like it last compiled successfully with Intel(R) Fortran 2021.5.0, that was part of oneAPI 2022.1.
I filed a bug, CMPLRLLVM-44982, for you. The fix won't make the next release; code freeze was last week.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You're welcome! Thanks RE the reproducer. Keeping them small definitely makes things easier. And thanks for accepting this as a bug. I'll look for updates in this thread for when it's resolved.
Is there a good rule of thumb to follow regarding how much time there is to submit issues for the next release when a compiler release comes out? E.g., if I submit an issue in the four weeks after a release, is there a chance it will be considered for the next release? Or is it more reasonable to think 2+ releases out? Knowing a bit more on this will help shape my team's plans for compiler evaluations as releases come out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Regarding on how to predict when an issue will be available in a release... There are oneAPI releases on about a quarterly cadence. It would make sense that the sooner an issue is reported after a release the more likely a fix will be available in the next release. BUT there are other factors involved -- implementing new features, developer workload, ease of fix, etc.
Do you know that you can mix and match object files, .mod files and libraries between ifx and ifort? That may help with your evaluation. See the ifort to ifx Porting Guide. There's a Porting Guide for icc to icx, too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Barbara_P_Intel wrote:
Regarding on how to predict when an issue will be available in a release... There are oneAPI releases on about a quarterly cadence. It would make sense that the sooner an issue is reported after a release the more likely a fix will be available in the next release. BUT there are other factors involved -- implementing new features, developer workload, ease of fix, etc.
Do you know that you can mix and match object files, .mod files and libraries between ifx and ifort? That may help with your evaluation. See the ifort to ifx Porting Guide. There's a Porting Guide for icc to icx, too.
See the response from @Barbara_P_Intel . You may get a fix in the next oneAPI release, or perhaps the next or a few cycles later. That is, it may be a relatively short wait, or a long one.
Thus an option for you will be to refactor your code such that you move away from the older "*char-length" form of the declaration to the one suggested starting Fortran 90 standard revision circa 1991 which may prove easier for your colleagues (who may be yourself in a new incarnation such as trying to read the code a little while after you authored it) and for Intel Fortran, say like so:
module mymod_m
type mytype_t
character :: achar
end type mytype_t
type(mytype_t) :: my_modvar
end module mymod_m
program variable_declaration_parse
use mymod_m
implicit none
character(len=len(my_modvar%achar)) :: achar
end program variable_declaration_parse
Or, better yet using named constants to be clear and explicit:
module mymod_m
integer, parameter :: LEN_ACHAR = 1
type mytype_t
character(len=LEN_ACHAR) :: achar
end type mytype_t
type(mytype_t) :: my_modvar
end module mymod_m
program variable_declaration_parse
use mymod_m
implicit none
character(len=LEN_ACHAR) :: achar
end program variable_declaration_parse
So that Intel Fortran processes the code for you with no errors:
C:\temp>ifx /c /free /standard-semantics p.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2023.0.0 Build 20221201
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
C:\temp>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The compiler engineers fixed this erroneous error message for both ifx and ifort in the latest versions. These were released last week as part of 2024.1.
Please give these compilers a try!

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