FreeBSD has a(nother) new C compiler: Intel oneAPI DPC++/C++
educational, developer, with an eye fixed in direction of a brighter techno-social life
[prev]
[next]
2024-03-06
FreeBSD has a(nother) new C compiler: Intel oneAPI DPC++/C++
A few months ago, we obtained Oracle Developer Studio to run on and output native binaries for FreeBSD. In the present day, let’s get one other proprietary compiler occurring FreeBSD: the Intel oneAPI DPC++/C++ Compiler. The most recent model of this compiler as of this weblog put up is 2024.0.2, and that is the model we’ll get working on FreeBSD. That is the brand new Intel compiler that makes use of the Clang frontend from the LLVM mission as its frontend, in distinction to the outdated model of the Intel compiler, which I consider used the Edison Design Group frontend. What makes the brand new Intel compiler fascinating is each the Clang frontend, which ought to simply work on FreeBSD as Clang is the built-in compiler for FreeBSD, and the backend, which is Intel’s customized and proprietary backend.
As talked about previously, a FreeBSD port of the outdated Intel C++ Compiler was created. It’s nonetheless within the ports tree, however it solely works on i386 and is model 8.1 of the compiler, released in September 2004. This replace is a very long time coming.
Let’s get began.
Organising the Linuxulator
Like with Oracle Developer Studio, it comes as Linux binaries; the Intel compiler is partially open supply so far as I perceive it. Meaning we might want to arrange the Linuxulator. I’m utilizing FreeBSD 14.0-RELEASE, the amd64 taste, so I’m going to comply with the FreeBSD Handbook, putting in the CentOS 7 base and libelf packages. The instructions you want are:
# sysrc linux_enable="YES" # service linux begin # pkg set up linux_base-c7 linux-c7-elfutils-libelf
And that is it. The CentOS 7 libraries, although outdated, are sufficient for the Intel compiler to work.
Putting in the compiler
First, I put in some instruments that we’ll want. The installer script wants the GNU df, tar, and bash. We might want to set up these:
# pkg set up bash coreutils gtar
I then wanted to ensure GNU df is discovered first and gtar can also be discovered first, and that they’re named df and tar. I did that by working:
$ mkdir ~/bin $ cd ~/bin $ cp /usr/native/bin/gdf df $ cp /usr/native/bin/gtar tar $ export PATH=~/bin:$PATH
Now the installer is not going to complain.
Let’s obtain and run the installer now. I need to set up the compiler to /choose/intel so I’ll make sure that to run the script as root:
$ cd $ fetch https://registrationcenter-download.intel.com/akdlm/IRC_NAS/bb99984f-370f-413d-bbec-38928d2458f2/l_dpcpp-cpp-compiler_p_2024.0.2.29_offline.sh $ sudo bash l_dpcpp-cpp-compiler_p_2024.0.2.29_offline.sh -a -s --eula settle for --ignore-errors
…however finally I gave up; whereas the set up completes, as a result of the installer can not discover G++ it doesn’t set up all of the applications, most notably the icx and icpx compilers. This can be a failing on Intel’s half: I’ve to think about the explanation the installer is searching for G++ is as a result of it thinks with out it, you do not have the required headers and libraries. However that is unfaithful on FreeBSD as these issues come put in by default. Putting in the gcc package deal doesn’t make things better, so Intel ought to enhance their set up program to make things better. Even so, there’s a --ignore-errors flag, and I believe that flag ought to ignore if G++ is lacking and easily set up every thing anyway.
There’s a workaround: I put in the compiler utilizing the identical command on my WSL setting on Home windows. I used to be then capable of bundle the ensuing /choose listing right into a tarball and transfer and extract the tarball on the FreeBSD machine. This labored advantageous, and now I’ve the compiler put in to /choose/intel. I additionally eliminated the ~/bin listing as that was solely wanted for set up and we did not set up it from the offered installer in spite of everything.
Utilizing the compiler
If I run /choose/intel/oneapi/compiler/newest/bin/icx --version, I get again:
Intel(R) oneAPI DPC++/C++ Compiler 2024.0.2 (2024.0.2.20231213) Goal: x86_64-unknown-linux-gnu Thread mannequin: posix InstalledDir: /choose/intel/oneapi/compiler/2024.0/bin/compiler Configuration file: /choose/intel/oneapi/compiler/2024.0/bin/compiler/../icx.cfg
This undoubtedly appears to be like like Clang. For comparability, if I run cc --version, I get again:
FreeBSD clang model 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) Goal: x86_64-unknown-freebsd14.0 Thread mannequin: posix InstalledDir: /usr/bin
This makes me surprise one thing: if Intel did not do all that a lot modification, might we persuade icx that it’s focusing on FreeBSD? On Clang, we might do that with the -target flag.
Certainly, if I run icx -target x86_64-unknown-freebsd14.0 --version, I get again this:
Intel(R) oneAPI DPC++/C++ Compiler 2024.0.2 (2024.0.2.20231213) Goal: x86_64-unknown-freebsd14.0 Thread mannequin: posix InstalledDir: /choose/intel/oneapi/compiler/2024.0/bin/compiler Configuration file: /choose/intel/oneapi/compiler/2024.0/bin/compiler/../icx.cfg
Yup, take a look at that. Now icx believes it’s focusing on FreeBSD. This considerably signifies that Intel might very merely and trivially present binaries for a minimum of FreeBSD, however most likely all of the BSDs, in the event that they needed to.
Let’s attempt to compile this hey world program:
#embody <stdio.h>
int major(void) { places("Howdy"); return 0; }
If we compile it with /choose/intel/oneapi/compiler/newest/bin/icx -v hey.c, we see:
Intel(R) oneAPI DPC++/C++ Compiler 2024.0.2 (2024.0.2.20231213) Goal: x86_64-unknown-linux-gnu Thread mannequin: posix InstalledDir: /choose/intel/oneapi/compiler/2024.0/bin/compiler Configuration file: /choose/intel/oneapi/compiler/2024.0/bin/compiler/../icx.cfg "/choose/intel/oneapi/compiler/2024.0/bin/compiler/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name hey.c -mrelocation-model static -fveclib=SVML -mframe-pointer=none -menable-no-infs -menable-no-nans -fapprox-func -funsafe-math-optimizations -fno-signed-zeros -mreassociate -freciprocal-math -fdenormal-fp-math=preserve-sign,preserve-sign -ffp-contract=quick -fno-rounding-math -ffast-math -ffinite-math-only -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -mllvm -x86-enable-unaligned-vector-move=true -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/house/brian -resource-dir /choose/intel/oneapi/compiler/2024.0/lib/clang/17 -internal-isystem /choose/intel/oneapi/compiler/2024.0/bin/compiler/../../choose/compiler/embody -internal-isystem /choose/intel/oneapi/compiler/2024.0/lib/clang/17/embody -internal-isystem /usr/native/embody -internal-externc-isystem /embody -internal-externc-isystem /usr/embody -O2 -fdebug-compilation-dir=/house/brian -ferror-limit 19 -fheinous-gnu-extensions -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops -vectorize-slp -D__GCC_HAVE_DWARF2_CFI_ASM=1 -fintel-compatibility -fintel-libirc-allowed -mllvm -disable-hir-generate-mkl-call -mllvm -loopopt=1 -floopopt-pipeline=mild -mllvm -intel-abi-compatible=true -o /tmp/icx-7df38f729d/hello-6860a3.o -x c hey.c clang -cc1 model 17.0.0 based mostly upon LLVM 17.0.0git default goal x86_64-unknown-linux-gnu ignoring nonexistent listing "/embody" #embody "..." search begins right here: #embody <...> search begins right here: /choose/intel/oneapi/compiler/2024.0/bin/compiler/../../choose/compiler/embody /choose/intel/oneapi/compiler/2024.0/lib/clang/17/embody /usr/native/embody /usr/embody Finish of search record. "/usr/bin/ld" --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/choose/intel/oneapi/compiler/2024.0/bin/compiler/../../lib -L/choose/intel/oneapi/compiler/2024.0/bin/compiler/../../lib -L/choose/intel/oneapi/compiler/2024.0/lib/clang/17/lib/x86_64-unknown-linux-gnu -L/choose/intel/oneapi/compiler/2024.0/bin/compiler/../../lib -L/lib/../lib64 -L/usr/lib/../lib64 -L/choose/intel/oneapi/compiler/2024.0/bin/compiler/../../lib -L/choose/intel/oneapi/compiler/2024.0/bin/compiler/../../choose/compiler/lib -L/lib -L/usr/lib /tmp/icx-7df38f729d/hello-6860a3.o -Bstatic -lsvml -Bdynamic -Bstatic -lirng -Bdynamic -Bstatic -limf -Bdynamic -lm -lgcc --as-needed -lgcc_s --no-as-needed -Bstatic -lirc -Bdynamic -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed -Bstatic -lirc_s -Bdynamic /usr/lib/crtend.o /usr/lib/crtn.o
That is shut. The compilation could be advantageous, however the linking is certainly not advantageous. Luckily, we all know the way to repair it.
Fixing up the Intel compiler
Equally to Oracle Developer Studio, the Intel compilers want a small wrapper program to assist them alongside. You may get away with a shell script, however I’ll use D to write down the wrapper applications. In contrast to Oracle Developer Studio, we need not manipulate the preprocessor defines because the -target flag does that for us. Altering the goal additionally adjustments the linker invocation to be right. The wrapper program appears to be like like this:
import std.course of;
int major(string[] args) {
string[] av;
av ~= "/choose/intel/oneapi/compiler/newest/bin/icx";
av ~= "-target";
model (FreeBSD_14) av ~= "x86_64-unknown-freebsd14.0";
else model (FreeBSD_13) av ~= "x86_64-unknown-freebsd13.0";
av ~= "-fno-builtin";
foreach (i; 1 .. args.size)
av ~= args[i];
return spawnProcess(av).wait;
}
Put it aside as icx.d after which all we have to do is compile it with LDC and we’ll be good:
$ ldc2 -O icx.d
That can create a binary named icx. I put it in /usr/bin however you possibly can put it in /usr/native/bin in case you have been going to make this right into a port or one thing.
Comparable must be achieved for the icpx wrapper:
import std.course of;
int major(string[] args) {
string[] av;
av ~= "/choose/intel/oneapi/compiler/newest/bin/icpx";
av ~= "-target";
model (FreeBSD_14) av ~= "x86_64-unknown-freebsd14.0";
else model (FreeBSD_13) av ~= "x86_64-unknown-freebsd13.0";
av ~= "-fno-builtin";
foreach (i; 1 .. args.size)
av ~= args[i];
return spawnProcess(av).wait;
}
Put it aside as icpx.d and run:
$ ldc2 -O icpx.d
And you should have your self an icpx binary.
Why the -fno-builtin?
Once you change the goal icx is compiling for, it tremendously adjustments the linker invocation. This really is smart, because the Linux libraries really rely upon glibc-specific options. For instance, something greater than trivial applications provides you with linker errors saying you might be lacking features equivalent to __vsnprintf_chk. This can be a bit unlucky; after I created a library with these features and linked it in, every thing labored advantageous. So once more, Intel might present a completely working compiler and help libraries for all of the BSDs in the event that they so select to. To avoid the necessity to use Intel’s help libraries, you add -fno-builtin.
The primary Intel compiler-built FreeBSD kernel?
As a check, I put in the FreeBSD 14.0-RELEASE supply code on my machine and constructed a kernel with:
# cd /usr/src # CC=icx COMPILER_TYPE=clang make buildkernel
After which I waited round for a little bit bit, however it did in reality full the construct. After I run readelf -x .remark /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel, I see the remark I’m anticipating: Intel(R) oneAPI DPC++/C++ Compiler 2024.0.2 (2024.0.2.20231223). The icx constructed kernel is about 3% bigger than the kernel that got here put in on the system.
I then ran make installkernel and as soon as confirming my new kernel was in reality put in, I rebooted the machine. To my absolute astonishment, it booted simply advantageous and put me into my X setting.
In a hilarious twist, the one factor that seems to have been miscompiled is the Linuxulator, as I get a bunch of those messages in my dmesg:
kldload: sudden relocation sort 42, image index 310 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file sort KLD linux.ko: will depend on linux_common - not accessible or model mismatch linker_load_file: /boot/kernel/linux.ko - unsupported file sort kldload: sudden relocation sort 42, image index 310 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file sort KLD linux64.ko: will depend on linux_common - not accessible or model mismatch linker_load_file: /boot/kernel/linux64.ko - unsupported file sort kldload: sudden relocation sort 42, image index 108 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/fdescfs.ko - unsupported file sort kldload: sudden relocation sort 42, image index 310 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file sort KLD linprocfs.ko: will depend on linux_common - not accessible or model mismatch linker_load_file: /boot/kernel/linprocfs.ko - unsupported file sort kldload: sudden relocation sort 42, image index 310 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file sort KLD linsysfs.ko: will depend on linux_common - not accessible or model mismatch linker_load_file: /boot/kernel/linsysfs.ko - unsupported file sort kldload: sudden relocation sort 42, image index 310 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file sort KLD linprocfs.ko: will depend on linux_common - not accessible or model mismatch linker_load_file: /boot/kernel/linprocfs.ko - unsupported file sort kldload: sudden relocation sort 42, image index 310 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file sort KLD linsysfs.ko: will depend on linux_common - not accessible or model mismatch linker_load_file: /boot/kernel/linsysfs.ko - unsupported file sort kldload: sudden relocation sort 42, image index 108 link_elf_obj: image __stack_chk_guard undefined linker_load_file: /boot/kernel/fdescfs.ko - unsupported file sort
After all, there might be extra issues which can be miscompiled, however solely the Linuxulator is what triggered as dangerous on my system.
C++
I didn’t check the C++ compiler as closely, however every thing I did throw at it compiled with out problem. I might be stunned if icpx would fail to compile something clang++ might compile.
Conclusion
The Intel oneAPI DPC++/C++ will run simply advantageous on FreeBSD. It’s actually production-quality for userland applications. It’s practically acceptable as a kernel compiler; it’d in reality already be acceptable, the issue might be in my wrapper program. It might be instantly improved by Intel really supporting FreeBSD with the help library and native compiler binaries; that is really fairly simple, however Intel could lack the desire to take action.
In any occasion, we will undoubtedly add the Intel compiler to compilers that may output native binaries for FreeBSD, and certain all of the BSDs. I believe that is neat.
