allocate LHS problem IFX2025.0.0

[andrew_4619]

This problem seems familiar maybe it is a variation on a previously reported issue but if so I can't find it. The example compiles and links  but crashes in memcpy at line 32. Please NOTE all the modules were in separate files. If I put them in one file like below it does NOT crash but runs ok!! 

If at 30 if I explicitly allocate parlabels(1)%Gitems(3) it does not crash. This is a digest of a code that is been running OK in Ifort for  several years.

The compiler options are:

COMPILE
/nologo /debug:full /Od /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /libs:static /threads /c

LINK
/OUT:"x64\Debug\ifx_test_2025_11.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST
/MANIFESTFILE:"x64\Debug\ifx_test_2025_11.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"C:\...\ifx_test_2025_11\x64\Debug\ifx_test_2025_11.pdb"
/SUBSYSTEM:CONSOLE /IMPLIB:"C:\...\ifx_test_2025_11\x64\Debug\ifx_test_2025_11.lib"

module mytypes ! file mytypes.f90
    implicit none(type, external)
    type :: T_dt_lab_item
        character(:), allocatable :: GElem
        character(:), allocatable :: GVarNm
    end type T_dt_lab_item
    type :: T_dt_lab
        character(:), allocatable  :: Gtyname
        type(T_dt_lab_item), allocatable :: Gitems(:)
    end type T_dt_lab
end module mytypes
module test_m ! file test_m.f90
    use mytypes, only: T_dt_lab,T_dt_lab_item
    implicit none(type, external)
    type (T_dt_lab), allocatable :: parlabels(:)
    interface
        module subroutine parlabels_init( istat )
            integer, intent(out) :: istat
        end subroutine parlabels_init
    end interface
end module test_m
submodule (test_m) test_SM1   ! file test_subm.f90
    implicit none(type, external)
    contains
    module subroutine parlabels_init( istat )
        integer, intent(out) :: istat
        allocate( parlabels(1), stat = istat )
        if(istat /= 0 ) return
        parlabels(1)%Gtyname = 'MAT'
     !  allocate(parlabels(1)%Gitems(3), stat = istat ) !>>>>>>> explicit allocate works, alloc LHS crashes
        if(istat /= 0 ) return
        parlabels(1)%Gitems  = [ T_dt_lab_item('NR',   '$AAA'), &
                                 T_dt_lab_item('ISET', '$BBBBBBB'), &
                                 T_dt_lab_item('GF',   '$FT') ]
    end subroutine parlabels_init
end submodule test_SM1
program ifx_test_2025_11   ! file ifx_test_2025_11.f90
    use test_m, only: parlabels_init
    implicit none(type, external)
    integer :: istat
    call parlabels_init( istat )
end program ifx_test_2025_11

[andrew_4619]

thought I would give this one a bump, seems like a bug to me......

[Devorah_H_Intel]

I can't reproduce the crash as provided. It would help to attach a zip file with a complete VS solution with source files included. 

[andrew_4619]

zip attached, I just built and re-tested in the debugger and it still bombs

[Ron_Green]

I am seeing an Internal Compiler Error when I split out the submodule test_SM1 to it's own source file.  This makes me think that there is a bug in the compiler with the uplevel reference(s) in submodule test_SM1.  I am tracing it down.  I will also test your zipfile.  I think that if the references in test_SM1 are bad, it may compile in your case but the references will cause a runtime segfault.

I will let you know what I find. but for sure there is a bug in the compiler 

[andrew_4619]

Yes separate files is key. My thoughts it is a namespace problem.

[Ron_Green]

@andrew_4619 you are somewhat correct.  It is a problem with the separately compiled submodule.  The error is that with ifx we created and pass additional information on the variable references that we pass down to our Intel proprietary optimizations phases in the middle end.  That additional proprietary information is the root cause.  When the module and submodule are in the same file, the struct we create to pass down to the middle end is correctly filled in.  For the case of separate compilation that information is not being constructed correctly.  It is a front-end issue but due to our proprietary extensions for our llvm compiler and our proprietary optimizations. 

We will let you know when this is resolved. 

Thank you for the testcase! 

[andrew_4619]

Thanks, there is also (maybe related or not) a raft of debugger not knowing about  a variable based on that sub-module pattern of usage. when someone works on this it may be worth considering checking the wider implications of the bug. I am to a degree double guessing how things work so may be way off the mark....