Make Intel's ICX compiler working
Hi hackers,
After having worked on [1]/messages/by-id/aa73q1aT0A3/vke/@ip-10-97-1-34.eu-west-3.compute.internal, I tried to make use of the Intel's ICX compiler [2]https://www.intel.com/content/www/us/en/developer/articles/technical/adoption-of-llvm-complete-icx.html.
While the compilation was ok for both autoconf and meson (meson version has to be
0.64 or greater, see [3]https://mesonbuild.com/Release-notes-for-0-64-0.html 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.575400999995The reason is that ICX defaults to -fp-model=fast enabling unsafe floating-point
optimizations (see [4]https://www.intel.com/content/www/us/en/developer/articles/guide/porting-guide-for-icc-users-to-dpcpp-or-icx.html).
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]/messages/by-id/abFXfKC8zR0Oclon@ip-10-97-1-34.eu-west-3.compute.internal).
The issue is solved by using the ICX -fp-model=precise flag (see [6]https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2025-1/fp-model-fp.html).
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]https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2025-1/no-intel-lib-qno-intel-lib.html).
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]: 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
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]: /messages/by-id/aa73q1aT0A3/vke/@ip-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]: /messages/by-id/abFXfKC8zR0Oclon@ip-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
Attachments:
v1-0001-Make-Intel-s-ICX-compiler-working.patchtext/x-diff; charset=us-asciiDownload+278-6
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
Hi,
On Wed, Mar 11, 2026 at 11:08:01AM -0400, Andres Freund wrote:
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.
Good point.
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.
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,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On 2026-03-11 18:10:55 +0000, Bertrand Drouvot wrote:
On Wed, Mar 11, 2026 at 11:08:01AM -0400, Andres Freund wrote:
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.
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?
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