IFX 2024.2.1 causes Linker Error on Windows

[KP_14]

This is a greatly simplified version of a program where I found a linker error when using IFX 2024.2.1. The program is within a Visual Studio project run with Visual Studio 2022 on Windows, but I took the commands it ran from the build log. I verified that the linker error still appears when running these commands from an "Intel oneAPI command prompt for Intel 64 for Visual Studio 2022" in the folder containing the source files. The example below was run to create 64-bit release mode executable (/O2), but I built for 64-bit debug and saw the same issue. I think the version of the MSVC linker shouldn't matter, since this looks like a compiler bug.

Commands:

1. ifx /nologo /O2 /module:"x64\Release\\" /object:"x64\Release\\" /libs:dll /threads /c /Qlocation,link,"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\bin\HostX64\x64" /Qm64 "message_types.F90"

2. ifx /nologo /O2 /module:"x64\Release\\" /object:"x64\Release\\" /libs:dll /threads /c /Qlocation,link,"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\bin\HostX64\x64" /Qm64 "foo.F90"

3. ifx /nologo /O2 /module:"x64\Release\\" /object:"x64\Release\\" /libs:dll /threads /c /Qlocation,link,"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\bin\HostX64\x64" /Qm64 "main.F90"

4. Link /OUT:"x64\Release\test_program.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"x64\Release\test_program.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /IMPLIB:"x64\Release\test_program.lib" "x64\Release\message_types.obj" "x64\Release\foo.obj" "x64\Release\main.obj"

Version: 2024.2.1 Build 20240711

Error: "foo.obj : error LNK2019: unresolved external symbol MESSAGE_TYPES_mp_BYTES.2 referenced in function WRITE_TEST"

I'm not sure exactly what causes this linker error. It seems to be related to the equivalence defined in message_types.F90 and then using that module like foo.F90 does. It looks like the name for a symbol defined in message_types.F90 gets mangled with a ".2" at the end in foo.obj, whereas message_types.obj has the correctly defined name. So the linker can't find this symbol due to how the compiler generated the object file.

message_types.F90

MODULE message_types

	IMPLICIT NONE
	PUBLIC
	
	INTEGER(KIND=4), PARAMETER :: MessagePayloadSize = 50
	INTEGER(KIND=4), PARAMETER :: MessageHeaderSize = 10
	INTEGER(KIND=4), PARAMETER :: FullMessageSize = 60
	
	TYPE :: MessageHeaderStructure
		SEQUENCE
		CHARACTER(LEN=1) :: Bytes(MessageHeaderSize)
	END TYPE
	
	TYPE :: MessagePayloadStructure
		SEQUENCE
		CHARACTER(LEN=1) :: Bytes(MessagePayloadSize)
	END TYPE
	
	TYPE :: MessageStructure
		SEQUENCE
		TYPE(MessageHeaderStructure)  :: Header
		TYPE(MessagePayloadStructure) :: Payload
	END TYPE
	
	TYPE :: FullMessageBytes
		SEQUENCE
		CHARACTER(LEN=1) :: Bytes(FullMessageSize)
	END TYPE
	
	TYPE(MessageStructure) :: Message
	TYPE(FullMessageBytes) :: Bytes
	EQUIVALENCE(Message,Bytes)

END MODULE message_types

foo.F90

MODULE foo

	USE message_types
	
	IMPLICIT NONE
	PRIVATE
	
END MODULE foo

SUBROUTINE Write_Test

	USE message_types
	
	TYPE(MessagePayloadStructure) :: Payload
	
	! Setup dummy message
	Message%Header%Bytes(1) = 'A'
	Message%Payload%Bytes(1) = 'B'
	
	Payload = Message%Payload
	WRITE (*,*) Payload%Bytes(1)
	
END SUBROUTINE Write_Test

main.F90

PROGRAM main

	USE foo
	
	CALL Write_Test

END PROGRAM main