[nvfortran] Assumed sized character variables inside OpenACC kernels regions

Hi,

What’s the official status on using assumed sized character variables inside OpenACC kernels regions with nvfortran? The example below provides 3 different kernels regions of increasing complexity:

  • the first started compiling with version 23.7, maybe simple due to some dead-code elimination;
  • the second never compiled;
  • and the third started compiling with version 23.7, but stopped compiling again with version 23.9.

Compile with nvfortran -c -acc=gpu ice.f90.

subroutine ice(a, c)
    real, intent(inout) :: a
    character(len = *), intent(in) :: c
    integer :: j

    ! Compiles with nvfortran 23.7 and 23.9
    !$acc kernels
    if (c == 'C') then
    end if
    !$acc end kernels

    ! Compiles with no nvfortran version
    !$acc kernels
    if (c == 'C') then
      do j = 1, 10
      enddo
    end if
    !$acc end kernels

    ! Compiles with nvfortran 23.7 only
    !$acc kernels
    if (c == 'C') then
      do j = 1, 10
        a = 1
      enddo
    end if
    !$acc end kernels
end subroutine ice

Cheers,
-Nuno

Hi Nuno,

That’s an odd one. I checked the issue report I have open for this and it doesn’t appear to have been worked on. I asked engineering, but it seems the working case was unexpected. We did track down what changes in the compiler caused it to work (if you use -O1, all three cases compile), but they seem unrelated. But may offer some clues to the root cause.

I’ve updated my report with this info and have asked management to see if we can bump the priority.

-Mat

if you use -O1, all three cases compile

Oh! Yes, with both -O0 and -O1, nvfortran 23.7 does manage to compile all three cases.
Could this possibly mean that there is one user-switchable optimisation option that is enabled at -O2 and above on 23.7 and on all levels on 23.9, that we could disable as a workaround?

It seems it still gives an ICE at -O0 with 23.9 so I don’t think there’s anything we can do as a work around. You could use 23.7 without optimization, but my guess is the bug is just getting masked and not really fixed, so might reappear in a real code.

FYI, Seth let me know that you contacted him directly and he reported the issue as TPR #34592.

1 Like