Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26748 Discussions

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

Martin1
New Contributor I
217 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
6 Replies
FortranFan
Honored Contributor II
202 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
201 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
185 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
179 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
182 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
165 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.


Reply