Error message from clang with ifx 2024.0?

[mhulsen]

Hi,

Just tested ifx in oneAPI version 2024.0 on Fedora 38. At the link step I get two strange error messages, for example:

ifx  -O3 -xHost  -fpe0 -stand f18 -o generalized_stokes_channel generalized_stokes_channel.o   -L../lib -ltfem -lexternal_ifx  -L/opt/intel/oneapi/mkl/2024.0/lib/intel64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lmetis 

/opt/intel/oneapi/compiler/2024.0/bin/compiler/clang-offload-bundler: error: unable to find 'llvm-objcopy' in path

/opt/intel/oneapi/compiler/2024.0/bin/compiler/clang-offload-bundler: error: unable to find 'llvm-objcopy' in path

The executable seems to run fine and the output results are fine as well.

Am I missing something in my system? I installed Intel Fortran and MKL using dnf:

dnf -y install intel-oneapi-compiler-fortran intel-oneapi-mkl

Martien

[Barbara_P_Intel]

Does a "hello world" program compiled with ifx report the same message?

ifx uses LLVM as the back end code generator. LLVM depends on some support from Clang.  Interesting... it seems like a warning message since your app runs ok.

Ah! I see you installed only Fortran and MKL. I wonder if you should also install DPC++ to pull in the Clang files.

[mhulsen]

A "hello world" program does not report the error message.

I tested a "hello world" program by added the libraries and I can confirm that the messages come from my own libraries libtfem.a and libexternal_ifx.a. Both are freshly made with ar and .o files from ifx only (no c or other languages). It also explains I get the message twice, once for each lib.

I can also confirm that after installing DPC++ (intel-oneapi-compiler-dpcpp-cpp)  the messages are gone. However, this requires a 2.3 Gbytes install just to get rid of the messages. Since I build a Docker image, this makes the image 50% larger than before.

Note, that the error messages were absent in previous versions of oneAPI (2023.x).

Martien

[Ron_Green]

I will check with the MKL team.  MKL has the ability to automatically offload computation to GPUs.  The "offload" is a clue.  It is possible they just added auto offload to the metis library.  Just a guess.  mkl_core could be the culprit also.  
Let. me check with my MKL colleagues on this.   Perhaps there is a non-offload version of core and/or metis that can be used.

[mhulsen]

I don't think it is related to MKL. As I said, the messages come from linking my own archive libaries (.a) that have been made from my own Fortran source files, compiled with ifx:

[tfemuser@36f750668cff ~]$ cat helloworld.f90 

print *, "hello world"

end

[tfemuser@36f750668cff ~]$ ifx helloworld.f90

[tfemuser@36f750668cff ~]$ ifx helloworld.f90 -L./tfem_develop/lib -ltfem

/opt/intel/oneapi/compiler/2024.0/bin/compiler/clang-offload-bundler: error: unable to find 'llvm-objcopy' in path

[Ron_Green]

Yes, this does look like a problem with the compiler paths and/or packaging.  I'll try an installation with just the Fortran compiler, create a library, and a driver main program linking into the library.  Thanks for catching this, I'll run some tests.

[Ron_Green]

This is a bug in our packaging of the Fortran-only component packages (IRC, downloads, repo packages).

I was somewhat on track with the diagnosis but it was deeper than I thought.

So yes, MKL has the ability to offload to Intel GPUs. Because of this, it has libraries with our proprietary "fat binary" object containing both host code and device code sections. Because of this, we have extended LLVM link tools to support our fat binary format.

So far so good.

But the people building our packages didn't think Fortran needed these tools. Because if a Fortran person wanted offload, they would need the C++ compiler and tools which packages these LLVM bin tools.

They didn't think about a Fortran + MKL user who would only want the Fortran compiler and MKL, and hence may want/need the LLVM binary tools to work with the new MKL libraries.

SO I wrote up a bug report and I'll get the team to put these into the next update release.

The linker will work, as you saw, it simply warns about the missing tool and simply ignores the GPU device code sections. So it works, just gives a confusing message in the process.

[Ron_Green · Accepted solution]

@mhulsen this bug is fixed in the 2024.1.0 compiler.