ICE with assumed-rank class(*), dimension(..) argument

[Martin1]

The ifort compiler ( ifort -V output is
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1 Build 20201112_000000 on Linux) fails with an ICE on the attached small program. It seems to be that it fails on the "class(*), dimension(..), optional" argument with assumed-rank. If the optional is removed, it still crashs. But if class(*) is replaced by an intrinsic type like integer or logical, it compiles (all with appropriates adjustments to the rest of the code of course).

[FortranFan]

@Martin1 ,

As you would know, an ICE is always a compiler bug.  Please submit this as support request at Intel OSC if you're able to.  https://supporttickets.intel.com/?lang=en-US

Otherwise, you'll have to wait for Intel staff to pick it up from here.

[FortranFan]

@Martin1 ,

It can take a while for ICEs to get resolved, as you may know.

In the meantime, a workaround you can employ in your code - i.e., if you're interested - is to use the ASSUMED TYPE - i.e, TYPE(*) - facility instead of unlimited polymorphic type:

..
function cssel(x) result(s)
   character(len=:), allocatable :: s
   type(*), dimension(..), optional, intent(in) :: x
   if (present(x)) then
..

By the way, I personally think assumed type is better suited for the simple case you show.

[Martin1]

---

@FortranFan  schrieb:

@Martin1 ,

It can take a while for ICEs to get resolved, as you may know.

In the meantime, a workaround you can employ in your code - i.e., if you're interested - is to use the ASSUMED TYPE - i.e, TYPE(*) - facility instead of unlimited polymorphic type:

..
function cssel(x) result(s)
   character(len=:), allocatable :: s
   type(*), dimension(..), optional, intent(in) :: x
   if (present(x)) then
..

By the way, I personally think assumed type is better suited for the simple case you show.

---

Thanks for pointing out type(*), I had forgotten about this addition to fortran. However, this is only a much boiled down variant of the original code (a pretty printing function for debug purposes: throw any small number of variables of any intrinsic and some other basic data types at it and it tries to produce debug output much better readable than a simple print * and no need to juggle with format specifiers), where I really want to select the type and rank of the argument.

[Martin1]

---

@FortranFan  schrieb:

@Martin1 ,

It can take a while for ICEs to get resolved, as you may know.

In the meantime, a workaround you can employ in your code - i.e., if you're interested - is to use the ASSUMED TYPE - i.e, TYPE(*) - facility instead of unlimited polymorphic type:

..
function cssel(x) result(s)
   character(len=:), allocatable :: s
   type(*), dimension(..), optional, intent(in) :: x
   if (present(x)) then
..

By the way, I personally think assumed type is better suited for the simple case you show.

---

Actually my "work-around" from the days where there were no assumed-rank arrays in sight was to use derived-types vector and matrix with a 'class(*), dimension(:), allocatable' and 'class(*), dimension(:,:), allocatable' components, respectively. But assumed-rank arguments save a bit of typing (no vector and matrix constructors).

[Martin1]

---

@FortranFan  schrieb:

@Martin1 ,

As you would know, an ICE is always a compiler bug.  Please submit this as support request at Intel OSC if you're able to.  https://supporttickets.intel.com/?lang=en-US

Otherwise, you'll have to wait for Intel staff to pick it up from here.

---

For those without support contract, the forum is the new bug tracker, as you might already have read.

[Barbara_P_Intel]

I filed a bug on your behalf on this ICE. The bug ID is CMPLRIL0-33513. I'll keep this thread posted on its progress to a fix.

[Barbara_P_Intel]

That ICE you reported is fixed in ifort 2021.6.0. It's included with oneAPI HPC Toolkit 2022.2 that was recently released.

Give it a try!