Nvfortran internal compiler error using derived types with `class(*)` variable

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

I ran into an internal compiler error while building a larger Fortran code base (GitHub - NOAA-GFDL/FMS: GFDL's Flexible Modeling System). I created a much smaller reproducer for the error. It’s related to a variable in a derived type that is class(*).

module test_mod
implicit none

 type fmsDiagOutputBuffer_type
  class(*), allocatable :: buffer(:) !< Causing the issue
 end type

 type fmsDiagObject_type
   type(fmsDiagOutputBuffer_type),dimension(:), allocatable :: FMS_diag_output_buffers !< Type within a type.  The function func returns one of these
   contains
   procedure func
 end type

 type(fmsDiagObject_type) :: obj

 contains

  function func (this, bufferid) &
  result(rslt)

   class(fmsDiagObject_type), intent(in)     :: this
   integer, intent(in)                       :: bufferid
   type(fmsDiagOutputBuffer_type),allocatable:: rslt

   if( (bufferid .gt. UBOUND(this%FMS_diag_output_buffers, 1)) .or. &
     (bufferid .lt. LBOUND(this%FMS_diag_output_buffers, 1))) &
       write(*,*) 'get_diag_bufer: invalid bufferid given'
   rslt = this%FMS_diag_output_buffers(bufferid)
 end function

end module

I tried compiling in a container on a grace hopper system using nvfortran 25.5. I also tried on an x86 system using 25.1 and in a container using 25.7 and got the same error:

NVFORTRAN-F-0000-Internal compiler error. chk_assign_sptr: not enough dimensions 0 (test.F90: 29)
NVFORTRAN/x86-64 Linux 25.7-0: compilation aborted

If I switch the type of buffer to real, the code compiles. In my actual code, the buffer array is 5 dimensions, and going down to one didn’t change the error reported.

I successfully compiled this with gfortran, ifx, and aocc flang.

2

Hi Tom,

Thanks for the report and reproducing example!

I was able to recreate the error here and created issue report TPR #37631. I’ve asked engineering to investigate.

-Mat

3

Hi Tom,

Engineering let me know that as a work around, you can change:

rslt = this%FMS_diag_output_buffers(bufferid)

with:

allocate(rslt, source=this%FMS_diag_output_buffers(bufferid))

-Mat

4

Thanks for the update. This type of function return occurs in a lot of places in our code base, so it would be an undertaking to implement this workaround. I’ll see if there’s desire from the team to implement it.

5

FWIW, I tested your repro with the Flang compiler (that , as Mat has mentioned several times, will be the foundation for an upcoming Nvidia compiler) and it is able to compile your code.

6

Hi Tom,

FYI, TPR #37631 has been fixed in our 25.9 release.

-Mat

7

Thanks for the update.