# Support for submodules in nvfortran **URL:** \ **Category:** Help\ **Created:** [January 27, 2023, 6:01pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097 "2023-01-27T18:01:35Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![jr\_reuter](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jr_reuter/32/352_2.png) [@jr\_reuter](https://fortran-lang.discourse.group/u/jr_reuter)\ **Post date:** [January 27, 2023, 6:01pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/1 "2023-01-27T18:01:35Z")
Today I gave a try to the newly released nvfortran 23.1. Is it known when there will be support for submodules in nvfortran? ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [January 28, 2023, 1:33am UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/2 "2023-01-28T01:33:04Z")
I think complete support for F2008 and F2018 in nvfortran is deferred until new-flang (llvm flang) is ready for prime time. At the rate (or lack of) that new FLANG is progressing, I doubt it will be anytime soon. It’s disappointing (at least to me) that I can’t do a sudo apt install llvm-flang etc and get a working (as in generate an executable binary) compiler ---
**Author:** ![jr\_reuter](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jr_reuter/32/352_2.png) [@jr\_reuter](https://fortran-lang.discourse.group/u/jr_reuter)\ **Post date:** [January 30, 2023, 9:31am UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/3 "2023-01-30T09:31:13Z")
Thanks for the answer, rwmsu. Indeed, I was testing the llvm-flang myself some time ago, and it is a lot of different things one has to compile before being able to try it out. And then, if there are updates it is not clear to me if it is sufficient to update the repo of flang from time to time, or one better needs to git-pull also llvm repo. In any case, what scares me away is that this is only a parser, and does not really compile/assemble code, such that one needs a running (back-end) compiler in addition. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [January 30, 2023, 3:05pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/4 "2023-01-30T15:05:04Z")
Another issue I have is that none of the LLVM based compilers (nvfortran, AMD AOCC, or ifx) will compile one of my codes without generating an ICE. No problems with ifort or gfortran. The code is standard F2003 with some F2008 that is supposed to be supported by nvfortran etc. Yes, I know compilers are compicated pieces of software but to me an ICE is just a sign of inadequate or poorly implemented internal testing. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [January 30, 2023, 3:39pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/5 "2023-01-30T15:39:20Z")
> [@rwmsu](#): > > Another issue I have is that none of the LLVM based compilers (… ifx) will compile one of my codes without generating an ICE. No problems with ifort … @rwmsu , re: `IFX`, if your code encountering ICE is online someplace, or if you can post a reproducer here, chances are high someone from Intel Fortran team will follow-up and work to get `IFX` resolved, particularly if the code works with `IFORT`. You can also post about it at the Intel Fortran forum. ---
**Author:** ![Aurelius\_Nero](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@Aurelius\_Nero](https://fortran-lang.discourse.group/u/Aurelius_Nero)\ **Post date:** [January 30, 2023, 4:58pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/6 "2023-01-30T16:58:54Z")
I think the work around for this, is some weird compiler flag (I forgot what it is 😅 ) > [@rwmsu](#): > > Another issue I have is that none of the LLVM based compilers (nvfortran, AMD AOCC, or ifx) will compile one of my codes without generating an ICE. Also what’s an ICE ? ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [January 30, 2023, 6:27pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/7 "2023-01-30T18:27:58Z")
@Aurelius_Nero , ICE = Internal Compiler Error. Unfortunately, my code that generates one is too large and too complicated to reduce to a simple reproducer. The fact that the none of the LLVM compilers work and two (nvfortran and AOCC) generate ICE in the same subroutine (with similar error messages) indicates its something inherent to LLVM (or maybe the old PGI frontend in “classic-flang”). Actually, the previous (not 2023) release of ifx did compile O.K at least for the one time I tried it. Current one doesn’t so its a regression of some kind. ---
**Author:** ![Aurelius\_Nero](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@Aurelius\_Nero](https://fortran-lang.discourse.group/u/Aurelius_Nero)\ **Post date:** [January 30, 2023, 6:39pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/8 "2023-01-30T18:39:48Z")
Hmm. > [@rwmsu](#): > > ICE = Internal Compiler Error. Thanks. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [April 15, 2024, 3:07pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/9 "2024-04-15T15:07:41Z")
Submodules appear to be available with the 24.1 release of the NVHPC SDK: [Nvfortran error with submodules - nvc, nvc++ and nvfortran - NVIDIA Developer Forums](https://forums.developer.nvidia.com/t/nvfortran-error-with-submodules/270536) ---
**Author:** ![jr\_reuter](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jr_reuter/32/352_2.png) [@jr\_reuter](https://fortran-lang.discourse.group/u/jr_reuter)\ **Post date:** [April 15, 2024, 3:55pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/10 "2024-04-15T15:55:17Z")
Not really. very simple constructions fail to compile, e.g. the code below fails with NVFORTRAN-S-0155-Derived type has not been declared - t1\_node\_t (binary\_tree.f90: 37) 0 inform, 0 warnings, 1 severes, 0 fatal for ```auto module t1 implicit none private type :: t1_iterator_t integer, dimension(:), allocatable :: key contains procedure :: init => t1_iterator_init end type t1_iterator_t type :: t1_node_t end type t1_node_t type :: t1_t type(t1_node_t), pointer :: root => null () end type t1_t interface module subroutine t1_iterator_init (iterator, btree) class(t1_iterator_t), intent(inout) :: iterator type(t1_t), target :: btree end subroutine t1_iterator_init end interface end module t1 submodule (t1) t1_s implicit none contains module subroutine t1_iterator_init (iterator, btree) class(t1_iterator_t), intent(inout) :: iterator type(t1_t), target :: btree type(t1_node_t), pointer :: node contains subroutine fill_key (node) type(t1_node_t), pointer, intent(out) :: node end subroutine fill_key end subroutine t1_iterator_init end submodule t1_s ``` ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [April 15, 2024, 4:05pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/11 "2024-04-15T16:05:02Z")
> [@jr\_reuter](#): > > `type :: t1_node_t` Given that you declared your module private, here you should declare ```auto type, public :: t1_node_t ``` Then, it compiles without problems with nvfortran 24.1 ---
**Author:** ![jr\_reuter](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jr_reuter/32/352_2.png) [@jr\_reuter](https://fortran-lang.discourse.group/u/jr_reuter)\ **Post date:** [April 15, 2024, 4:21pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/12 "2024-04-15T16:21:19Z")
No, the submodule should access all entities of its parent module or parent submodule by host association, cf. J3/24-007, Sec. 5.2.5. This is a compiler syntax parsing error. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [April 15, 2024, 4:35pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/13 "2024-04-15T16:35:14Z")
> [@jr\_reuter](#): > > This is a compiler syntax parsing error. You are most probably right! This doesn’t bother ifort or gfortran, nor even flang-new. Then, in a slightly different subject about `implicit none` [The standard says "An - Intel Community](http://community.intel.com/t5/Intel-Fortran-Compiler/Scope-of-IMPLICIT-statement-in-SUBMODULES/m-p/1098727#M126226) I just learned that a submodule is its own scope, so it seems like in practice one could make mistakes by assuming that everything is inherited. (I was personally seen submodules as a kind of “extended scope”) ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [April 15, 2024, 4:46pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/14 "2024-04-15T16:46:13Z")
nvfortran 24.3 also fails unless you declare t1\_node\_t public. It compiles correctly then. ---
**Author:** ![jr\_reuter](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jr_reuter/32/352_2.png) [@jr\_reuter](https://fortran-lang.discourse.group/u/jr_reuter)\ **Post date:** [April 15, 2024, 4:46pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/15 "2024-04-15T16:46:35Z")
The thread you linked is about implicit typing, not about using type declarations of the parent module. Intel ifort had a similar issue, which was confirmed as such by Steve Lionel: > **[Re:Intel oneAPI bug with submodules](https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-oneAPI-bug-with-submodules/m-p/1385713/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufEwzRENFNVhLSlVTVzlTfDEzODU3MTN8U1VCU0NSSVBUSU9OU3xoSw#M161396)** > > This erroneous error message is gone with ifort 2021.6.0 which is part of oneAPI HPC Toolkit 2022.2 that was recently released. Please check it out! ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [April 15, 2024, 4:53pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/16 "2024-04-15T16:53:08Z")
I guess this a good mwe to open a thread at the nvfortran Forum [https://forums.developer.nvidia.com/](https://forums.developer.nvidia.com/), they usually reply quite fast. ---
**Author:** ![jr\_reuter](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jr_reuter/32/352_2.png) [@jr\_reuter](https://fortran-lang.discourse.group/u/jr_reuter)\ **Post date:** [April 15, 2024, 6:08pm UTC](https://fortran-lang.discourse.group/t/support-for-submodules-in-nvfortran/5097/17 "2024-04-15T18:08:26Z")
I reported this in April 2022, > **[Nvfortran compilation error on valid code: submodule](https://forums.developer.nvidia.com/t/nvfortran-compilation-error-on-valid-code-submodule/211609/2)** > > Thanks Jurgen. This is a known issue reported as TPR #27323. I added your test case to this report and asked engineering to increase the priority. -Mat still waiting for it to be fixed. In flang-new it is working