You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are seeing problems with the latest Intel classic compilers (icc@2021.9.0, icpc@2021.9.0; part of Intel's oneAPI@2023.1.0) on a new machine called Hercules (Mississippi State University / NOAA; Rocky Linux release 9.1 (Blue Onyx)).
Here is an example traceback for one of our ctests fv3jedi_test_tier1_hyb-fgat_fv3lm (cont'd below).
The automatic detection of HAVE_FINAL in fckit's cmake config enables the feature. If I turn off the FINAL feature manually in the cmake build, the above errors are gone.
As part of my investigation I spent a bit of time cruising around in the fckit code and cmake files and I found several places that hint to problems with the FINAL feature in fckit itself. For example, there are build flags like FCKIT_FINAL_BROKEN_FOR_ALLOCATABLE_ARRAY and FCKIT_FINAL_BROKEN_FOR_AUTOMATIC_ARRAY that simply turn off related tests etc.
I am not entirely sure what the reasoning behind relying on auto-detecting the FINAL feature by default is, but from all that I've seen and not knowing what you know, I would expect the default for HAVE_FINAL to be OFF, and any user setting it to ON should be greeted with big bold warnings?
What are the steps to reproduce the bug?
The only system on which I currently have access to this particular version of oneAPI is MSU Hercules, therefore I cannot say if it is just the compiler or a combination of the compiler PLUS the machine. A slightly earlier version of Intel (2021.8.0, part of oneAPI@2023.0.0) did not have this problem with the finalization of the shared pointers (but had other problems that were indeed bugs in the compiler that forced us to move on to the latest version).
Version
0.10.1
Platform (OS and architecture)
Linux hercules-login-4.hpc.msstate.edu 5.14.0-162.12.1.el9_1.0.2.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jan 30 22:14:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux / Rocky Linux release 9.1 (Blue Onyx)
Relevant log output
see above
Accompanying data
n/a
Organisation
JCSDA
The text was updated successfully, but these errors were encountered:
Hi @climbfuji
I have also come to realise that the FINAL feature should probably not be enabled by default anymore.
Different compilers tend to behave differently and it is hard to predict all things that could go wrong.
It has in my recent experience also caused some issues.
Also I should add some more extensive tests to at least detect errors of the sort you described with ENABLE_FINAL=ON.
I am ok to disable this feature by default.
I can make this change of default, including a warning when enabling, for the next release.
It should be noted though that memory leaks will occur if "final" method is then not called manually.
@wdeconinck Any updates on this issue? So far we entertain logic in the spack recipe for fckit to turn off AUTO_FINAL if the compiler is intel@2021.8.0 or later and it's trying to autodetect the setting. If the user turns it on and uses intel@2021.8.0` or later, spack will abort.
What happened?
We are seeing problems with the latest Intel classic compilers (
icc@2021.9.0
,icpc@2021.9.0
; part of Intel'soneAPI@2023.1.0
) on a new machine called Hercules (Mississippi State University / NOAA; Rocky Linux release 9.1 (Blue Onyx)).Here is an example traceback for one of our ctests
fv3jedi_test_tier1_hyb-fgat_fv3lm
(cont'd below).The automatic detection of
HAVE_FINAL
in fckit's cmake config enables the feature. If I turn off theFINAL
feature manually in the cmake build, the above errors are gone.As part of my investigation I spent a bit of time cruising around in the fckit code and cmake files and I found several places that hint to problems with the FINAL feature in fckit itself. For example, there are build flags like
FCKIT_FINAL_BROKEN_FOR_ALLOCATABLE_ARRAY
andFCKIT_FINAL_BROKEN_FOR_AUTOMATIC_ARRAY
that simply turn off related tests etc.I am not entirely sure what the reasoning behind relying on auto-detecting the FINAL feature by default is, but from all that I've seen and not knowing what you know, I would expect the default for HAVE_FINAL to be OFF, and any user setting it to ON should be greeted with big bold warnings?
What are the steps to reproduce the bug?
The only system on which I currently have access to this particular version of oneAPI is MSU Hercules, therefore I cannot say if it is just the compiler or a combination of the compiler PLUS the machine. A slightly earlier version of Intel (
2021.8.0
, part ofoneAPI@2023.0.0
) did not have this problem with the finalization of the shared pointers (but had other problems that were indeed bugs in the compiler that forced us to move on to the latest version).Version
0.10.1
Platform (OS and architecture)
Linux hercules-login-4.hpc.msstate.edu 5.14.0-162.12.1.el9_1.0.2.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jan 30 22:14:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux / Rocky Linux release 9.1 (Blue Onyx)
Relevant log output
Accompanying data
n/a
Organisation
JCSDA
The text was updated successfully, but these errors were encountered: