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
