Function with same name as intrinsic function in submodule leads to ICE

There are numerous bug reports related to Fortran submodules, so I’m not entirely if this is new. But I couldn’t find the ICE reported anywhere. I have this test code:

module foo_m

  implicit none
  private
  !!!public :: merge

  interface merge
     module procedure merge_this
  end interface

  interface
    module subroutine merge_this (x)
      integer, intent(in) :: x
    end subroutine merge_this
  end interface

end module foo_m

submodule (foo_m) foo_s
  implicit none
contains
  module subroutine merge_this (x)
    integer, intent(in) :: x
  end subroutine merge_this

  subroutine use_merge ()
    call merge(1)
  end subroutine use_merge
end submodule foo_s 

When compiling it with nvfortran 24.11, I get this generic internal compiler error:

nvfortran-Fatal-/home/cweiss/local/hpc_sdk/Linux_x86_64/24.11/compilers/bin/tools/fort1 TERMINATED by signal 11

The code compiles when I declare merge as public. Also, when I replace merge by a different name (and do not declare the interface public), I instead get this error:

NVFORTRAN-S-0155-Could not resolve generic procedure merge_loc

I assume that in the case of just merge, the compiler tries to use the intrinsic Fortran routine, which does not fit here.

In my understanding, submodules should be able to access private components from parent modules. That nvfortran cannot do so seems to be a known problem, right? Is there any workaround except for going through the code and putting the adequate public statements everywhere?

Hi Christian,

Thanks for the report. I added issue TPR#36810 and sent it to engineering. Looks like the front-end compiler is getting into some type of infinite loop and ultimately crashing the stack causing the segv.

Private components are accessible by submodules, and we do support this, however your example is hitting a unique case that’s not being handled.

-Mat

Hi Mat,

thanks for reporting this issue.
I cannot confirm that nvfortran fully supports access to private components of parent modules. For example, just replace merge in the above example by any other name and leave out the public statement, and you get the second error message in my post. I have encountered this issue in several other situations and could provide some more examples if time permits.

Hi Christian,

FYI, TPR #36810 has been fixed in 25.1 and the example file above now compiles successfully.

-Mat