Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
27667 Discussions

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

Martin1
New Contributor I
400 Views

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

0 Kudos
7 Replies
FortranFan
Honored Contributor II
385 Views

@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
Honored Contributor II
384 Views

@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
New Contributor I
368 Views

@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
New Contributor I
362 Views

@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
New Contributor I
365 Views

@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
Moderator
348 Views

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
Moderator
153 Views

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!



Reply