For the record, this was your call when the Regtest were sorted out. Now you're doing it yourself; much appreciated!

Sorry for the confusion. This is just to test the water.
Since I can't build these containers on my AMD machine at home, I decided to open this draft PR.
I still think we should try to merge #4547 first.

It doesn't look too good: While the ifort gets stuck on grid_dgemm_prepare_pab.c the ifx struggles to parse DBCSR.

It doesn't look too good: While the ifort gets stuck on grid_dgemm_prepare_pab.c the ifx struggles to parse DBCSR.

I think, I prepared DBCSR for Intel Compiler and had various updates at the CMake compiler spec level, etc. This is not part of any recent DBCSR v2.8.0. Can you try something like dbcsr@develop?

Regarding the grid_dgemm_prepare_pab.c, this is a case I reported and it was fixed. Note, using "Intel Fortran Classic" aka IFORT still uses the non-classic C/C++ Compiler (ICX). Unfortunately, the mentioned fix was after 2024.2 which is however the last package version which is shipping IFORT. The workaround for grid_dgemm_prepare_pab.c in this case is to limit the optimization level to -O2.

I prepared DBCSR for Intel Compiler ... Can you try something like dbcsr@develop?

Switching to DBCSR's development branch definitely helped.

@alazzaro, would it be possible to make a DBCSR release before the upcoming CP2K release?

@alazzaro, would it be possible to make a DBCSR release before the upcoming CP2K release?

That's the plan. I will release a RC candidate next week.

That's the plan. I will release a RC candidate next week.

Awesome. Thanks!

To be honest, I'm struggling a bit with this PR. @hfp, maybe you could take a look?

These Intel tests are actually the last place where the CI uses the Makefile.

It'd be great if we could delete the Makefile by the end of next week, so that we still have some time before the release.

Updating here for completeness https://github.com/cp2k/dbcsr/releases/tag/v2.9.0

Updating from oneapi-hpckit:2025.2.2-0 to oneapi-hpckit:2025.3.0-0 is not a good idea since IFX 2025.3 regressed (I am on it). See also #4553 (comment).

I rebased onto DBCSR 2.9.0 and went back to oneapi-hpckit:2025.2.2-0. Unfortuantely, not much has changed:

• ifort still crashes

• ifx fails with a linker error:

  /usr/bin/ld: /lib/x86_64-linux-gnu/Scrt1.o: in function `_start':
  (.text+0x1b): undefined reference to `main'
  

I rebased onto DBCSR 2.9.0 and went back to oneapi-hpckit:2025.2.2-0. Unfortuantely, not much has changed:

* ifort still [crashes](https://storage.googleapis.com/cp2k-ci/run-cp2k-intel-ifort-ssmp-fea5b11a_report.txt)

* ifx fails with a [linker error](https://storage.googleapis.com/cp2k-ci/run-cp2k-intel-ifx-ssmp-f224b590_report.txt):
  ```
  /usr/bin/ld: /lib/x86_64-linux-gnu/Scrt1.o: in function `_start':
  (.text+0x1b): undefined reference to `main'
  ```

We have some workarounds appended when generating the ARCH-file (overriding Makefile rules), but no equivalent yet for the CMake based approach. I can take over and work on it. Results are more likely post-holiday...

I can take over and work on it.

That would be great!

Results are more likely post-holiday...

Yeah, I know. The usual end of year rush :-)

I guess it would have been smarter to conclude the CMake migration with our mid-year release.

However, now that we're almost there, I really want to put the lid on. To ensure nothing was forgotten, it would be good if I could delete the Makefile before the holidays.

So.... do you think it would be ok to merge this PR as is and break the intel tests for a few days?

That's fine too. Once we have migrated, I can also enable some currently unsupported combinations. For instance, GNU Fortran and Intel MPI/MKL are a good "team". It's my own preferred recipe. I worked upstream on Spack to make the mentioned combo working already.

As a side note, I am potentially holding back some PRs for post-release (targeting DBM, Offload, and some CP2K components).