Subject: Make Intel's ICX compiler working

From: Bertrand Drouvot <[email-masked]>
Date: Wed, 11 Mar 2026 14:44:11 +0000

Hi hackers,

After having worked on [1], I tried to make use of the Intel's ICX compiler [2].

While the compilation was ok for both autoconf and meson (meson version has to be
0.64 or greater, see [3] that added the ICX support), I ran into a couple of issues
when running the test suite.

1/ Issue on floating point

The tests were failing with issues such as:

--- /home/postgres/postgresql/postgres/src/test/regress/expected/time.out
+++ /home/postgres/postgresql/postgres/src/test/regress/results/time.out
@@ -225,8 +225,8 @@
 (1 row)

 SELECT date_part('epoch',       TIME '2020-05-26 13:30:25.575401');
-  date_part
---------------
- 48625.575401
+     date_part
+--------------------
+ 48625.575400999995

The reason is that ICX defaults to -fp-model=fast enabling unsafe floating-point
optimizations (see [4]).

This is the same class of optimizations that we guard against by rejecting
-ffast-math in autoconf (BTW, we don't guard against in meson, I think we should
do the same, and it has been proposed in [5]).

The issue is solved by using the ICX -fp-model=precise flag (see [6]).

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]).

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.

Remarks:

For autoconf, ICX is detected thanks to the __INTEL_LLVM_COMPILER macro (see,
[8]) and for meson with the compiler id "intel-llvm" (see [9]).

With those in place the tests run without any issues.

Regarding -no-intel-lib, we may want specific libraries to exclude, but excluding
all looks safer.

We could also think about having some BF animals with ICX and/or maybe a dedicated
cirrus task.

Looking forward to your feedback.

[1]: https://postgr.es/m/aa73q1aT0A3/vke/%40ip-10-97-1-34.eu-west-3.compute.internal
[2]: https://www.intel.com/content/www/us/en/developer/articles/technical/adoption-of-llvm-complete-icx.html
[3]: https://mesonbuild.com/Release-notes-for-0-64-0.html
[4]: https://www.intel.com/content/www/us/en/developer/articles/guide/porting-guide-for-icc-users-to-dpcpp-or-icx.html
[5]: https://postgr.es/m/abFXfKC8zR0Oclon%40ip-10-97-1-34.eu-west-3.compute.internal
[6]: https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2025-1/fp-model-fp.html
[7]: https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2025-1/no-intel-lib-qno-intel-lib.html
[8]: https://www.intel.com/content/www/us/en/developer/articles/technical/use-predefined-macros-for-specific-code-for-intel-dpcpp-compiler-intel-cpp-compiler-intel-cpp-compiler-classic.html
[9]: https://mesonbuild.com/Reference-tables.html

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Andres Freund <[email-masked]>
Date: Wed, 11 Mar 2026 11:08:01 -0400

Hi,

> 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

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.

> The issue is solved by making use of -no-intel-lib ([7]).

So their runtime is too buggy to be used as well.

> so PFA, a patch implementing those changes for both autoconf and meson.

-many without some very very very good reasons.

Greetings,

Andres Freund

---

From: Bertrand Drouvot <[email-masked]>
Date: Wed, 11 Mar 2026 18:10:55 +0000

Hi,

> thinks defaulting to generating wrong results is a sane idea, I don't trust

Good point.

> -many without some very very very good reasons.

The reasoning was that without the patch, one could still compile with ICX and
get silent errors or worst segfault later on. The patch idea was to prevent
those. That said, I agree that ICX looks buggy, so maybe we should just
error out if we detect it's being used?

Regards,

---

From: Andres Freund <[email-masked]>
Date: Wed, 11 Mar 2026 14:19:03 -0400

Hi,

> error out if we detect it's being used?

I don't think it's worth doing anything about random new compilers until
there's actually bogus reports coming in.  If the compiler developers want to
test postgres with their new thing, what's the gain from making that harder?

Greetings,

Andres Freund