lld-link issues when using ifx instead of ifort

[aristotelis42]

I have a large project in VS2022 that builds fine with ifort. However, switching to ifx (after seeing the compiler message about becoming deprecated) leads to some errors.

I managed to narrow down the issue to the following error:

error: x64\Debug\ONDAM.obj: CHSOD.alias should not refer to special section 0

For context, I have a file called chsod.f containing a subroutine with the same name (not inside a module). The subroutine uses a lot of custom modules which is hard to turn off to see if they are causing this issue.

Any advice on how to track down the source of the problem would be greatly appreciated.

[Barbara_P_Intel]

What version of ifx are you using? 2024.0.0 is the latest.

How are ONDAM and CHSOD related?

It looks like you are building a debug version. What compiler options are you using?

It's hard to offer much advice without a reproducer.

[aristotelis42]

I am using the latest version of ifx. 

ONDAM is the module that contains the subroutine that calls CHSOD.

In terms of the flags used, please see below:

compiler:
/nologo /debug:full /Od /fpp /I"..\common_modules\x64\Debug\\" /D_DEBUG /warn:interfaces /module:"..\common_modules\x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc170.pdb" /traceback /check:bounds /libs:qwin /dbglibs /c

linker:
/OUT:"x64\Debug\ISISf64_DEBUG.exe" /LIBPATH:"..\..\..\..\SDK\Licensing\FM_Security\x64\Debug_DLL" /LIBPATH:"..\..\..\..\Dependencies\xmdf\library\lib" /LIBPATH:"..\ISIS_Output_Quickwin\x64\Debug\\" /NODEFAULTLIB:"msvcrtd.lib" /MANIFEST:NO /DEBUG /PDB:"x64\Debug\ISIS.pdb" /MAP /MAPINFO:EXPORTS /SUBSYSTEM:WINDOWS /STACK:100000000 /LARGEADDRESSAWARE /IMPLIB:"x64\Debug\ISIS.lib" zlibdlldx64.lib validate_licence_library.lib software_protection.lib ISIS_Output_Quickwin.lib mkl_intel_thread_dll.lib mkl_intel_lp64_dll.lib

To be fair, the build is through Visual Studio if that makes any difference.

I will try to create a minimal example to reproduce, but it might not be easy (or might not capture the complexity of the original code).

[Jacob_Williams]

I am having the same problem (Windows, Visual Studio 2019, ifx 2024.2, Debug build). In my case it's with some legacy Fortran 77 files that have compiled and run fine for decades.

It's happening at link time. Everything compiles fine but then it won't link, and error is "<subroutine name>.alias should not refer to special section 0". I'm also trying to narrow down the problem and come up with a reproducer that I can send.

The Release build also works fine.

[Devorah_H_Intel]

@Jacob_Williams, could you submit your VS solution via an Online Service Center case for us to investigate? 

[Jacob_Williams]

Yes, I will try to do this when I can extract some kind of example I can send. Will update here when I do that.

[Jacob_Williams]

It tells me:

Not Eligible for Priority Support

The information you are trying to access is not available at this time. Please try again later. Sorry for any inconvenience.

[Jacob_Williams]

OK, here is a reproducer of the problem. Unzip bug.zip and you will see a VS solution and two source files.

Try building the Debug configuration in Visual Studio, and I get the error:

x64\Debug\file2.obj: BLAH.alias should not refer to special section 0.

The Release build doesn't have this problem (note: you will still get an undefined symbol error, but that's just because this example doesn't include all the files).

[Devorah_H_Intel]

---

@Jacob_Williams wrote:

OK, here is a reproducer of the problem. Unzip bug.zip and you will see a VS solution and two source files.

Try building the Debug configuration in Visual Studio, and I get the error:

x64\Debug\file2.obj: BLAH.alias should not refer to special section 0.

The Release build doesn't have this problem (note: you will still get an undefined symbol error, but that's just because this example doesn't include all the files).

---

I was able to reproduce the error in the debug config.  This case is escalated to compiler engineering for further investigation. 

Just to be clear, in your actual project, in release config builds with no error at all, and the debug build only produces the above error?

[Jacob_Williams]

Yes, in my real project, Release builds without errors, and Debug only produces the error mentioned. (the simple example I uploaded is not complete but is only to show the error). It's old-fashioned code with external functions but it has worked for many years with ifort (I converted it to .f90 for the example but it had the same issue as fixed-form format).

[Devorah_H_Intel]

This issue will be fixed in 2025.1 IFX. 

The workaround is not to use 

/warn:interfaces

for this particular case.  
@Jacob_Williams