Something broke between 2024.0 and 2024.1

[Jellby1]

Compilation of OpenMolcas worked fine with 2024.0, now since 2024.1 it's broken. The program compiles, but running it fails (in some cases) with hard to debug errors.

git clone https://gitlab.com/Molcas/OpenMolcas.git
cd OpenMolcas
mkdir build
cd build
FC=ifx CX=icx cmake -D LINALG=MKL ..
make -j
./pymolcas verify 003

 This fails with (look in the test/tmp/standard__003.err file):

caspt2.exe: pthread_mutex_lock.c:94: ___pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
forrtl: error (76): Abort trap signal
Image              PC                Routine            Line        Source
libc.so.6          00007F9990B83520  Unknown               Unknown  Unknown
libc.so.6          00007F9990BD79FC  pthread_kill          Unknown  Unknown
libc.so.6          00007F9990B83476  raise                 Unknown  Unknown
libc.so.6          00007F9990B697F3  abort                 Unknown  Unknown
libc.so.6          00007F9990B6971B  Unknown               Unknown  Unknown
libc.so.6          00007F9990B7AE96  Unknown               Unknown  Unknown
libc.so.6          00007F9990BD90D0  pthread_mutex_loc     Unknown  Unknown
caspt2.exe         000000000083158A  Unknown               Unknown  Unknown
caspt2.exe         0000000000826996  Unknown               Unknown  Unknown
caspt2.exe         000000000082652C  Unknown               Unknown  Unknown
caspt2.exe         000000000085EBBF  Unknown               Unknown  Unknown
caspt2.exe         0000000000820179  Unknown               Unknown  Unknown
caspt2.exe         00000000005931C5  isfreeunit                 71  isfreeunit.F90
caspt2.exe         0000000000706EFB  irdone                     88  irdone.F90
caspt2.exe         00000000005B67F9  rdone_internal             37  rdone.F90
caspt2.exe         00000000005B65A0  rdone                      26  rdone.F90
caspt2.exe         00000000004B14D0  traone                     73  traone.f
caspt2.exe         000000000043F4B3  intctl1                    23  intctl1.f
caspt2.exe         000000000043CDDB  grpini                    111  grpini.f
caspt2.exe         0000000000409D82  caspt2                    235  caspt2.f
caspt2.exe         0000000000408C4F  main                       11  main.f
caspt2.exe         0000000000408C0D  Unknown               Unknown  Unknown
libc.so.6          00007F9990B6AD90  Unknown               Unknown  Unknown
libc.so.6          00007F9990B6AE40  __libc_start_main     Unknown  Unknown
caspt2.exe         0000000000408B25  Unknown               Unknown  Unknown

This particular failure can be solved with the following modification:

$ git diff
diff --git a/src/molcas_ci_util/CMakeLists.txt b/src/molcas_ci_util/CMakeLists.txt
index b8a8aa93a..5b94dcce7 100644
--- a/src/molcas_ci_util/CMakeLists.txt
+++ b/src/molcas_ci_util/CMakeLists.txt
@@ -132,3 +132,5 @@ set (modfile_list
 )
 
 include (${PROJECT_SOURCE_DIR}/cmake/util_template.cmake)
+
+set_source_files_properties(nrcoup.F90 PROPERTIES COMPILE_FLAGS -O0)

but it doesn't make much sense to me. As I said, it worked with 2024.0, and it works with other compilers (gfortran, nvfortran, nagfor).

[andrew_4619]

What about 2024.2? 

[Jellby1]

2024.2 is like 2024.1 (it crashes).

[andrew_4619]

Interesting but the cmake stuff is a bit gibberish to me as I don't use it.  I will say I got a weird crash in 2024.2. I made a simple example in this thread https://community.intel.com/t5/Intel-Fortran-Compiler/Exception-in-IFX-2024-2-0-Intel-R-64/m-p/1610145#M172758 that no one has commented on as yet. Maybe you have problems like that?  Anyway if you have a minute build my example  and see if it is the same for you. It bothers me that if that example fails there could be many such problems.

[Jellby1]

The cmake stuff simply means add the "-O0" compilation flag when compiling that particular file (nrcoup.F90).

[Jellby1]

Sorry for the noise, I think this is just the same as https://community.intel.com/t5/Intel-Fortran-Compiler/Wrong-results-in-apparently-simple-loop/m-p/1592647. First, I had just forgotten about that one (and it's only 2 months ago!); and second, for some reason it was harder to debug this time.

[Devorah_H_Intel · Accepted solution]

---

@Jellby1 wrote:

Sorry for the noise, I think this is just the same as https://community.intel.com/t5/Intel-Fortran-Compiler/Wrong-results-in-apparently-simple-loop/m-p/1592647. First, I had just forgotten about that one (and it's only 2 months ago!); and second, for some reason it was harder to debug this time.

---

This one is fixed in the 2025.0 release.