Intel launched the 2024.0 versions of our Intel Software Developer Tools. The announcement is posted here on our User Forum.
Intel Software Developer Tools 2024.0 Highlights
Intel developer tools now maximize performance on upcoming Intel 5th Generation Xeon Scalable Processors (formerly known as Emerald Rapids) and the Intel® Core Ultra processors (formerly known as Meteor Lake).
It was indeed much easier to download and install than previous ifort versions but my first test of f2023 features revealed that the AT and LZP edit descriptors had not been implemented, and neither had the input/output keyword LEADING_ZERO.
We post a webpage, updated at each release and update, with current feature sets. Here
we will roll out F23 over a couple of years. I’ll take back your ask for AT and LZP edit descriptors and put them up near the top in the priority list.
Although the latest ifort works fine, and I appear to have ifx also available, I do not understand the error message I got when trying to use it, possibly because I haven’t knowingly used llvm.
/opt/intel/oneapi/compiler/2024.0/bin/compiler/clang-offload-bundler: error: unable to find 'llvm-objcopy' in path
Dear Ron.
I know this is not the correct venue, but I’ve been complaining about this bug in the oneAPI forum since July and still there is no resolution.
I’ve been unable to update the oneAPI suite in my Fedora Core using the official rpm packages provided by Intel.
This is the URL of the thread:
Now that oneAPI 2024.0 is incorporating the new features of the 2023 standard, I would really like to be able to update the suite.
Thanks.
Taking into account that ifort is apparently not being enhanced anymore (left on 2021.11.0 version) I’ve given the ifx a try. First thing I’ve found, which might be useful for other users, those on Linux machines, is that an ifx-compiled executable (no extra options given) depends on shared libraries located in OneAPI tree. This is not the case for ifort. It means that outside of Intel environment (setup by sourcing /opt/intel/oneapi/setvars.sh file) the executable won’t work.
There is a simple fix, however, one has to add -Wl,-rpath=/opt/intel/oneapi/compiler/2024.0/lib option to ifx invocation.
Apparently the above trick is fixing the lack of “libimf.so” file but not the other libraries which have both .so and .so.N files, e.g. libintlc.so.5.
I had to add also “-L /opt/intel/oneapi/compiler/2024.0/lib” option to ifx to fix that.
-static-intel would be my recommendation.
If the code uses OpenMP you’ll need -qopenmp-link=static in addition to -static-intel. qopenmp-link static-intel
Using -static-intel option fixes the problem. Well, actually it is not very much of a problem. I have just noticed the difference between ifort and ifx. Looks like ifort has this option ON by default.
Incidentally, the man pages of bothifort and ifx state that the Intel libraries are linked statically by default (which makes sense!), with the exception of openMP and coarray runtime libraries.
Apparently this is not true for ifx so maybe it should be updated in the documentation.
I think you found a bug in our ifx driver. the default SHOULD BE static. and if you compile with
-dryrun
or
-#
to dump all the driver settings you will see that MOST of the Intel libraries are proceeded by -Bstatic. libimf might have slipped through the cracks. I will research this and correct it. Thank you for bringing this to my attention.
You’re welcome
There is another one, libintlc if I remember correctly. That one has appeared on “not found” list after adding -rpath option and required additional -L option. The difference I see is that libimf.so is full-size library file but for the other one, the so file is neither full-size nor symbolic link to so.5. Instead, it contains “INPUT libintlc.so.5” directive, apparently not recognised properly by the loader.
IIRC the classic compilers icc, icpc, and ifort are no longer included in the Intel oneAPI stacks in the 2024.0 distribution. The several previous versions prior to this have been spewing out deprecation warnings if you tried to use them.
Edit: The official deprecation announcement can be accessed here on the Intel forum:
The deprecation warning looks like this:
$ which ifort
/opt/intel/oneapi/compiler/2024.0/bin/ifort
$ ifort --version
ifort: remark #10448: Intel(R) Fortran Compiler Classic (ifort) is now deprecated and will be discontinued late 2024. Intel recommends that customers transition now to using the LLVM-based Intel(R) Fortran Compiler (ifx) for continued Windows* and Linux* support, new language support, new language features, and optimizations. Use '-diag-disable=10448' to disable this message.
ifort (IFORT) 2021.11.1 20231117
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.
I have to confess that the way the OneAPI is distributed in repositories for Linux is a source of constant pain. The dependencies in the repositories are weird and any upgrade is heavy to do right on its own even if there were no other issues. But even worse are the issues with the public key for the signatures of the packages. I try to delete the repository and add it again with the hope of the key getting sorted but it really is a pain.