Make Intel's ICX compiler working

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