Hi, On 2026-03-11 14:44:11 +0000, Bertrand Drouvot wrote: > After having worked on [1], I tried to make use of the Intel's ICX compiler > [2].
Why? We removed icc support because it was barely maintained and buggy. Why would we expect ICX to be different? What would we gain by supporting what is essentially an LLVM fork? > The reason is that ICX defaults to -fp-model=fast enabling unsafe > floating-point > optimizations (see [4]). That alone makes me extremely hesitant to support it. If a compiler vendor thinks defaulting to generating wrong results is a sane idea, I don't trust them. > 2/ Issue on ICX's default runtime libraries > > For example, I was observing: > > postgres: postgres regression [local] CREATE SUBSCRIPTION: Relink > `/opt/intel/oneapi/compiler/2025.3/lib/libimf.so' with > `/lib/x86_64-linux-gnu/libm.so.6' for IFUNC symbol `cosf' > > followed by a SIGSEGV. > > The reason is that ICX by default links against Intel runtime libraries such > as > libimf.so, which provide IFUNC-based replacements for standard math functions > (e.g. > cosf). When shared libraries built with ICX are loaded into a process that > also uses the system libm.so.6, the dynamic linker encounters conflicting > IFUNC resolvers and segfaults. > > The issue is solved by making use of -no-intel-lib ([7]). So their runtime is too buggy to be used as well. > I think that it makes sense to have ICX working (we took care of ICC in the > past), > so PFA, a patch implementing those changes for both autoconf and meson. -many without some very very very good reasons. Greetings, Andres Freund
