Community
cancel
Showing results for 
Search instead for 
Did you mean: 
mani_e204
Beginner
162 Views

Potential ifort 19 bug

I just stumbled upon some weird behavior in ifort 19.1.0.166 on CentOS 7. I am not entirely sure if this is a bug with the compiler or if it's non-standard Fortran so I wanted to ask here. Below is a MWE that illustrates the issue:

program test
   implicit none

   integer, allocatable :: a(:), b1(:), b2(:, :)

   b1 = [2, 1]
   b2 = reshape([1, -1, -2, -3, -4, 2, -5, -6, -7, -8], [5, 2])

   a = b1(b2(1, :))
   write(*, *) shape(a), "|", a
end program test

What's important is that the output of this program depends on whether one uses runtime checks (-C) or not. Basically, we use b2(1, (which is just [1, 2]) to index b1 (which should yield [2, 1]) to automatically allocate a to [2, 1]. So the expected output should be:

           2 |           2           1

However, after enabling runtime checks, the output changes to:

           1 |           2

 Is there something wrong with the code? I do believe all of this should be valid Fortran (2003).

0 Kudos
4 Replies
Arjen_Markus
Valued Contributor III
136 Views

I would say it is conforming. I can also confirm that the program works with Intel Fortran 2018, with and without -C (or -check:all). I get the same answer. gfortran also accepts it and produces the same output.

Steve_Lionel
Black Belt Retired Employee
115 Views

Also broken in 2021.1.2.

Barbara_P_Intel
Moderator
67 Views

I traced the issue down to -check shape.  It's embedded in -C.  

Here's a workaround

+ ifort -C -check noshape c.f90
+ a.out
           2 |           2           1

I filed a bug on your behalf,  CMPLRIL0-33624. I'll let you know when there's a fix.

mani_e204
Beginner
54 Views

Great! Thanks a lot, I appreciate it.