Nvfortran Constant Array Initialization Bug

Accelerated Computing HPC Compilers nvc, nvc++ and nvfortran
1

I’ve encountered an internal compiler error for what seems to be valid according to all other major compilers. The issue is encountered when trying to select along an array axis for constant data

A MWE is:

program check

    implicit none

    integer, parameter :: N = 5
    integer, parameter :: V1(N,4) =   reshape((/0, 0, 0, 1, &
                                                0, 0, 1, 1, &
                                                0, 0, 1, -1, &
                                                4, -1, 0, -1, &
                                                2, -2, 0, 1/), &
                                            shape(V1),order=(/2,1/))
    integer, parameter :: V1COL(N) = V1(:,2)         

    write(*,*) V1COL

end program check

The expected result is:

           0           0           0          -1          -2

For nvfortran, we get the following:

NVFORTRAN-S-0000-Internal compiler error. initialization expression: invalid array subscripts
       5  (/app/example.f90: 12)
  0 inform,   0 warnings,   1 severes, 0 fatal for check
Compiler returned: 2

I’ve tried messing around with different ways of specifying the array subscripts to try and track if it was an issue of how things were specified in its mind, but I haven’t come across something that satisfies.

The attached Godbolt link has a conformance view for other major compilers: link

Thanks for your help

2

Hi zcobell1,

Thank you for sharing this ICE! I have created an internal report #37108 to report this issue to engineering and hopefully they’ll be able to resolve it!

One quick workaround, of course, is to not make V1COL a parameter, and then to set “V1COL(:) = V1(:,2)” after the declaration section. However, I believe our compiler should handle this piece of code as written, so hopefully engineering can get this cleared up for you quickly!

Thanks again, and feel free to report any other issues you run into!

Cheers,

Seth.

3

Thanks Seth! We’d implemented a similar runtime workaround. Appreciate you sending this upstream.