IFX in OneAPI-IA32 command window: refuses to compile but proceeds to link!

[mecej4]

We know that IFX will not produce 32-bit objects and EXEs. In a Windows OneAPI-IA32 command window, if I forget this and issue a compile-link command, IFX will refuse to compile and issues a message. Nevertheless, if the corresponding OBJ file exists (from an Ifort-IA32 compilation, or was previously produced by another compiler), IFX proceeds to hand over the stale/alien OBJ file to the linker and produces an EXE, which is rather confusing. The confusion is compounded by the title of the One-API 32-bit command window: "Inte(R) MPI Library Build Environment for Intel(R) 64 applications" -- nothing to remind the user "This is a 32-bit build environment, so don't try using IFX".

I have OneAPI 2024.0 installed. The file hw.f90 is a two line "hello world" program.

S:\LANG>del *.exe

S:\LANG>ifort /nologo hw.f90 & hw
 Hello world

S:\LANG>ifx /nologo hw.f90 & hw
hw.f90: error #5535: Target architecture IA-32 is not supported.
 Hello world

S:\LANG>del hw.obj & ifx /nologo hw.f90 & hw
hw.f90: error #5535: Target architecture IA-32 is not supported.
LINK : fatal error LNK1181: cannot open input file 'hw.obj'
'hw' is not recognized as an internal or external command,
operable program or batch file.

[Ron_Green · Accepted solution]

that is odd.  Intel MPI only supports x64, has not supported ia-32 for probably 10 years or more.  But the Command WIndow just sets up paths to the compiler, and these would have the ifort paths for both 32 and 64bit.

I haven't tried this myself.   Now the Fortran Runtime Library is shared between ifort and ifx.  so we do have 32bit versions of all FRTL libs that we provide for ifort.   You know that ifx is a driver that calls the backend compiler, xfortcom.  ifort calls fortcom.  Both drivers can also function to drive the linking as well as the compilation.  If you pass just 32bit obj files, it very well may simply toss these over to the Microsoft linker.  it would find the 32bit FRTL files I think.  

It's not a supported use model.  I haven't tried this.

For sure when we release 2025.0 without the 32bit FRTL the link will fail.  but that isn't until Q4 of this year (2024).

[Ron_Green]

Barbara tested this scenario.  She reproduced what you are seeing.

Although the behavior of the ifx driver may not be what you expected, it is not a bug.  When the driver is driving the link step, it simply passes references to the objects and libs to the system linker.  The system linker is responsible for trying to combine objects of the same architecture. 

It's not the job of the driver to double check all your objs and libraries.  That falls to the linker.  Imagine the slow down if every obj/lib file had to be examined to determine it's architecture.  and the additional logic needed to alert the user to the problems.  No, it is far more efficient to let the linker handle error and odd scenarios.  

So I do not see a bug here.  The driver is complex enough, it need not also have to handle all possible linkage scenarios.