LLVM only spack-stack using no ifort (ifx, icc and icpc and MPI wrappers around these) generally needed on RDHPCS platforms for UFS LLVM testing.

[GeorgeVandenberghe-NOAA]

THere is a general need to upgrade the compiler level and build LLVM only stacks on all NOAA platforms because as of issue creation date, Intel classic ifort is a year out of support (Dec 2024) and NOAA applications need spack-stack depencencies to build with LLVM. This writer (George V) has built his own stacks to advance such testing but for more general app testing we need spack-stack envrionments. UFS_Weather-Model coupled though does not build until intel/2025.2 or higher is available and the GOCART component does not build until intel/2025.3 is made available so systems such a spack-stack is built on need to be at these levels of Intel. LLVM model and CLASSIC dependencies is fully supported by the compiler but very difficult to implement with spack-stack.

[climbfuji]

FYI neptune-env alreayd builds with LLVM, and NEPTUNE runs with it (clang, clang++, flang-new). That was a non-trivial effort. Our NOAA (EMC, EPIC) colleagues will have to take care of the rest that is needed for the UFS. Not in spack-stack-2.0.0, but maybe as soon as 2.1.0 in February 2026.

[eap]

@GeorgeVandenberghe-NOAA I don't fully understand the request here, are you asking

(1) That we move away from ifort and replace it with ifx.

(2) That we support all llvm compilers including icc and clang.

(3) That we deprecate both ifort and the dual-stack packages like this where some packages are built with GCC due to oneapi compiler compatibility?

If the request here is just the second one, then we should be meeting this with the spack-stack 2.0 release. The other requests require more effort as dom has noted.

[climbfuji]

Unfortunately, there are parallel threads here and in the ufs-weather-model repo, which leads to confusion, and then there is the additional confusion about the terminology.

Just to get the terminology right:

• "LLVM" or "native LLVM" = LLVM compilers from the LLVM project, clang/clang++/flang-new
• "Intel Classic" = icc + icpc + ifort (last ever release of icc and icpc was oneapi 2023.2.0)
• "Intel Mixed" = icx + icpx + ifort (last ever release of ifort was oneapi 2024.2.1)
• "Intel LLVM" = icx + icpx + ifx

In terms of spack-stack support in spack-stack-2.0.0

• LLVM 21.x.y supported for NEPTUNE standalone environment only
• Intel Classic support dropped except for WCOSS2/Acorn, all support from @AlexanderRichert-NOAA
• Intel Mixed deprecated, support will be removed in spack-stack-2.1; only supported versions are oneapi 2024.2.0 and 2024.2.1
• Intel LLVM fully supported, version 2025.3.0

There is no intention to entirely remove the "feature" to compile certain packages with GCC - why should we compile cmake with Intel LLVM if we never link to it.

[GeorgeVandenberghe-NOAA]

*Short term I am asking for spack stack on all NOAA R&D systems with no icc, icpc or ifort content (classic). * I am not sure how ifx and icx map to CLANG but we need stacks that use ony Intel currently supported compilers as soon as possible. A mixed stack with ifort is out of support for intel since Dec 2024. A mixed stack with gcc is still under support and not nearly as much concern because gnu has continuing support. This is coming up on MY desk because we are looking at preparing an NCEP bencmark and do not want to include any requirements for unsupported compiler components (ifort is the one that keeps popping up). Upon examining the problem I found it very difficult to test our applications with pure LLVM environments because of lack of spack-stack support and because of at least one bug in the dependency stack (w3emc.. needs upgrade and fix is to upgrade and document)

…

On Mon, Jan 5, 2026 at 12:25 PM Evan Parker ***@***.***> wrote: *eap* left a comment (JCSDA/spack-stack#1859) <#1859 (comment)> @GeorgeVandenberghe-NOAA <https://github.com/GeorgeVandenberghe-NOAA> I don't fully understand the request here, are you asking *(1)* That we move away from ifort and replace it with ifx. *(2)* That we support all llvm compilers including icc and clang. *(3)* That we deprecate *both* ifort and the dual-stack packages like this <https://github.com/JCSDA/spack-stack/blob/develop/configs/common/packages_oneapi.yaml#L15> where some packages are built with GCC due to oneapi compiler compatibility? If the request here is just the second one, then we should be meeting this with the spack-stack 2.0 release. The other requests require more effort as dom has noted. — Reply to this email directly, view it on GitHub <#1859 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDS4FXUNQ3ARITGFZZNTPL4FKNATAVCNFSM6AAAAACQNMMLXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJRGM4DENBSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- George W Vandenberghe *Lynker Technologies at * NOAA/NWS/NCEP/EMC 5830 University Research Ct., Rm. 2141 College Park, MD 20740 ***@***.*** 301-683-3769(work) 3017751547(cell)

[climbfuji]

*Short term I am asking for spack stack on all NOAA R&D systems with no
icc, icpc or ifort content (classic). * I am not sure how ifx and icx map
to CLANG but we need
stacks that use ony Intel currently supported compilers as soon as
possible. A mixed stack with ifort is out of support for intel since Dec
2024. A mixed stack with gcc is still under
support and not nearly as much concern because gnu has continuing support.

This is coming up on MY desk because we are looking at preparing an NCEP
bencmark and do not want to include any requirements for unsupported
compiler components (ifort is the one that keeps popping up). Upon
examining the problem I found it very difficult to test our applications
with pure LLVM environments because of lack of spack-stack support and
because of at least one bug in the dependency stack (w3emc.. needs upgrade
and fix is to upgrade and document)
…

Let me just emphasize to please use the terminology I mentioned above to avoid confusion. If you mean Intel LLVM compilers, then say "Intel LLVM". If you say "pure LLVM environments" then that refers to the native LLVM compilers coming from the open-source LLVM project (clang, clang++, flang-new), which is not what you want I believe.

[GeorgeVandenberghe-NOAA]

Thanks MUCH for clarification. This will make my future communications less confusing for everyone else so I will lock down these terms from here on out.

…

On Mon, Jan 5, 2026 at 12:33 PM Dom Heinzeller ***@***.***> wrote: *climbfuji* left a comment (JCSDA/spack-stack#1859) <#1859 (comment)> Unfortunately, there are parallel threads here and in the ufs-weather-model repo, which leads to confusion, and then there is the additional confusion about the terminology. Just to get the terminology right: - "LLVM" or "native LLVM" = LLVM compilers from the LLVM project, clang/clang++/flang-new - "Intel Classic" = icc + icpc + ifort (last ever release of icc and icpc was oneapi 2023.2.0) - "Intel Mixed" = icx + icpx + ifort (last ever release of ifort was oneapi 2024.2.1) - "Intel LLVM" = icx + icpx + ifx In terms of spack-stack support in spack-stack-2.0.0 - LLVM 21.x.y supported for NEPTUNE standalone environment only - Intel Classic support dropped except for WCOSS2/Acorn, all support from @AlexanderRichert-NOAA <https://github.com/AlexanderRichert-NOAA> - Intel Mixed deprecated, support will be removed in spack-stack-2.1; only supported versions are oneapi 2024.2.0 and 2024.2.1 - Intel LLVM fully supported, version 2025.3.0 There is no intention to entirely remove the "feature" to compile certain packages with GCC - why should we compile cmake with Intel LLVM if we never link to it. — Reply to this email directly, view it on GitHub <#1859 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDS4FXCJX2YLP6LXBTAQO34FKN6BAVCNFSM6AAAAACQNMMLXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJRGQYDOOJYGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- George W Vandenberghe *Lynker Technologies at * NOAA/NWS/NCEP/EMC 5830 University Research Ct., Rm. 2141 College Park, MD 20740 ***@***.*** 301-683-3769(work) 3017751547(cell)

[GeorgeVandenberghe-NOAA]

You are correct and I might have missed that if not for your clarification. I will use IntelLLVM from here on out.

…

On Mon, Jan 5, 2026 at 12:42 PM Dom Heinzeller ***@***.***> wrote: *climbfuji* left a comment (JCSDA/spack-stack#1859) <#1859 (comment)> *Short term I am asking for spack stack on all NOAA R&D systems with no icc, icpc or ifort content (classic). * I am not sure how ifx and icx map to CLANG but we need stacks that use ony Intel currently supported compilers as soon as possible. A mixed stack with ifort is out of support for intel since Dec 2024. A mixed stack with gcc is still under support and not nearly as much concern because gnu has continuing support. This is coming up on MY desk because we are looking at preparing an NCEP bencmark and do not want to include any requirements for unsupported compiler components (ifort is the one that keeps popping up). Upon examining the problem I found it very difficult to test our applications with pure LLVM environments because of lack of spack-stack support and because of at least one bug in the dependency stack (w3emc.. needs upgrade and fix is to upgrade and document) … <#m_-7932937476328557191_> Let me just emphasize to *please* use the terminology I mentioned above to avoid confusion. If you mean Intel LLVM compilers, then say "Intel LLVM". If you say "pure LLVM environments" then that refers to the native LLVM compilers coming from the open-source LLVM project (clang, clang++, flang-new), which is not what you want I believe. — Reply to this email directly, view it on GitHub <#1859 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDS4FTHWQHAU4AEYHYL36D4FKPBRAVCNFSM6AAAAACQNMMLXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJRGQZTSMZSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- George W Vandenberghe *Lynker Technologies at * NOAA/NWS/NCEP/EMC 5830 University Research Ct., Rm. 2141 College Park, MD 20740 ***@***.*** 301-683-3769(work) 3017751547(cell)