Classic and IFX 2023.0.0 regression on Windows - error #7815: Recursive use of symbol. . .

[fortrandave]

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

[Steve_Lionel]

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.

[Barbara_P_Intel]

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.

[fortrandave]

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.

[Barbara_P_Intel]

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.

[FortranFan]

---

@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.

---

@fortrandave ,

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>

[Barbara_P_Intel]

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!