adding --version flag results in fortran runtime error

[ltalirz]

This is with cp2k 7.1 installed from conda forge on MacOS

cp2k.sopt --version
 CP2K version 7.1
 Source code revision git:e635599
 cp2kflags: omp no_statm_access accelerate
At line 249 of file /Users/runner/miniforge3/conda-bld/cp2k_1608812708261/work/src/start/cp2k.F (unit = 6, file = 'stdout')
Fortran runtime error: Missing initial left parenthesis in format


Error termination. Backtrace:
#0  0x10cb8b4dc
#1  0x10cb8c395
#2  0x10cb8cf55
#3  0x10d0f390d
#4  0x10d0f3d8c
#5  0x10d1098fb
#6  0x10a63d51b
#7  0x10bf1a12e

The reported line is

cp2k/src/start/cp2k.F

Line 249 in 40eef54

WRITE (output_unit, "(T2,A,A)") "compiler: ", compiler_version()

Looks like it is still present in current master

cp2k/src/start/cp2k.F

Line 290 in 2285224

WRITE (output_unit, "(T2,A,A)") "compiler: ", compiler_version()

[dev-zero]

interesting error message since the left parenthesis in the format string is obviously there

[dev-zero]

So far I am unable to reproduce this with CP2K v8.1+ built with either gcc or clang and gfortran-10.2 on macOS.

[ltalirz]

Thanks a lot for checking - do you get the same error as me when you install cp2k using

conda install -c conda-forge cp2k

?

It is possible that this is somehow caused by either the specific compiler combination or compiler flags on conda-forge.

Build log including compiler flags
archfile

Relevant flags might be:

CPPFLAGS=-D_FORTIFY_SOURCE=2 -isystem $PREFIX/include -mmacosx-version-min=10.9
FFLAGS=-march=core2 -mtune=haswell -ftree-vectorize -fPIC -fstack-protector -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/cp2k-7.1.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix
LDFLAGS_LD=-pie -headerpad_max_install_names -dead_strip_dylibs -rpath $PREFIX/lib -L$PREFIX/lib

Compiler versions

 cctools_osx-64:           949.0.1-h2f0f38f_19       conda-forge
    clang:                    11.0.0-h694c41f_2         conda-forge
    clang-11:                 11.0.0-default_h9e6edd0_2 conda-forge
    clang_osx-64:             11.0.0-hb91bd55_8         conda-forge
    clangxx:                  11.0.0-default_h9e6edd0_2 conda-forge
    clangxx_osx-64:           11.0.0-h7e1b574_8         conda-forge
    cmake:                    3.19.2-hb0787d7_0         conda-forge
    compiler-rt:              11.0.0-h01488ec_2         conda-forge
    compiler-rt_osx-64:       11.0.0-hd3c4e95_2         conda-forge
    expat:                    2.2.9-hb1e8313_2          conda-forge
    gfortran_impl_osx-64:     9.3.0-h8668ab3_15         conda-forge
    gfortran_osx-64:          9.3.0-h2de5253_10         conda-forge
    gmp:                      6.2.1-h2e338ed_0          conda-forge
    isl:                      0.22.1-hb1e8313_2         conda-forge
    krb5:                     1.17.2-h60d9502_0         conda-forge
    ld64_osx-64:              530-hea264c1_19           conda-forge
    ldid:                     2.1.2-h7660a38_2          conda-forge
    libclang-cpp11:           11.0.0-default_h9e6edd0_2 conda-forge
    libcurl:                  7.71.1-h9bf37e3_8         conda-forge
    libcxx:                   11.0.0-h4c3b8ed_1         conda-forge
    libedit:                  3.1.20191231-h0678c8f_2   conda-forge
    libev:                    4.33-haf1e3a3_1           conda-forge
    libffi:                   3.3-h046ec9c_2            conda-forge
    libgfortran:              5.0.0-h6c81a4c_15         conda-forge
    libgfortran-devel_osx-64: 9.3.0-h6c81a4c_15         conda-forge
    libgfortran5:             9.3.0-h6c81a4c_15         conda-forge

[oschuett]

Since the error message about the missing parenthesis is obviously bogus, we are most likely dealing with a compiler incompatibility that is not specific to CP2K. Hence, I'd suggest we close this issue.

[dev-zero]

... since a lot of other applications conda provides seem to be working there is a good chance that the problem is still explicitly linked to CP2K.

[oschuett]

From #1273 (comment) it seems that clang and gfortran were mixed. I guess, other Conda packages are simply not doing that.

[dev-zero]

yes, mixing clang and gfortran in a project where ISO_C_BINDING are used is usually not a good idea (the Fortran standard only guarantees compatibility for "companion compilers").
On the other hand I've tested the exact same combination on our Mac (tcopt1) and could not reproduce the issue.

[oschuett]

So, this issue is most likely not caused by CP2K and we can not reproduce it. I think, those are two good reason for closing it.

[dev-zero]

@ltalirz I've got an idea how we can start verifying the issue if you can get access to the faulty binary. The data (format string AND result from compiler_version()) passed to the print(...) function should be hardcoded in the binary. Here's the output on a minimal CP2K exe:

$ strings exe/minimal/cp2k.sdbg  | grep 'compiler'
--set, -E name=value : set the initial value of a preprocessor value (Development Version)(T2,A)CP2K version 9.0Source code revision git:8a5b25a-cpp -I /home/tiziano/work/cp2k/cp2k/src/start/ -I /home/tiziano/work/cp2k/cp2k/obj/minimal/sdbg/exts/dbcsr -D_REENTRANT -D __COMPILE_ARCH="minimal" -D __COMPILE_DATE="Thu Jan 28 05:12:17 PM CET 2021" -D __COMPILE_HOST="scarlet" -D __COMPILE_REVISION="git:8a5b25a" -D __DATA_DIR="/home/tiziano/work/cp2k/cp2k/data" -D __SHORT_FILE__="start/cp2k.F" -mtune=generic -march=x86-64 -fopenmp -ffree-form -fpre-include=/usr/include/finclude/math-vector-fortran.h(T2,A,A)compiler: GCC version 10.2.0compiler options:(T4,A)compiler_options_string
The compiler target flags (
Consider compiler target flags as part of FCFLAGS and CFLAGS (ARCH file).

If you check inside the there you'll see the (T2,A,A)compiler: GCC version 10.2.0.
Could you run this command on the faulty binary and post the results?

[ltalirz]

thanks for the suggestion!

if you can get access to the faulty binary.

Sure - just to be clear: anybody can get this binary on MacOS with conda install -c conda-forge cp2k.

Could you run this command on the faulty binary and post the results?

Here it is

$ strings /Users/leopold/Applications/miniconda3/bin/cp2k.ssmp | grep compiler
Source code revision git:e635599-cpp -I /Users/leopold/Applications/miniconda3/include -I /Users/runner/miniforge3/conda-bld/cp2k_1611173684068/work/src/start/ -I /Users/runner/miniforge3/conda-bld/cp2k_1611173684068/work/obj/Darwin-x86-64-conda/ssmp/exts/dbcsr -isysroot /Applications/Xcode_12.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -D__DYNAMIC__ -D __NO_STATM_ACCESS -D __ACCELERATE -D __FFTW3 -D __LIBXSMM -D __COMPILE_ARCH="Darwin-x86-64-conda" -D __COMPILE_DATE="Wed Jan 20 20:34:18 UTC 2021" -D __COMPILE_HOST="Mac-1611173522785.local" -D __COMPILE_REVISION="git:e635599" -D __DATA_DIR="/Users/runner/miniforge3/conda-bld/cp2k_1611173684068/work/data" -D __SHORT_FILE__="start/cp2k.F" -isystem /Users/leopold/Applications/miniconda3/include -march=core2 -mtune=haswell -mmacosx-version-min=10.9 -O2 -std=f2008 -ftree-vectorize -fPIC -fstack-protector -fdebug-prefix-map=/Users/runner/miniforge3/conda-bld/cp2k_1611173684068/work=/usr/local/src/conda/cp2k-7.1.0 -fdebug-prefix-map=/Users/leopold/Applications/miniconda3=/usr/local/src/conda-prefix -fbacktrace -ffree-form -fimplicit-none -fopenmp(T2,A,A)compiler: GCC version 9.3.0compiler options:(T4,A)(A)
The compiler target flags () used to build
   this binary cannot exploit all extensions of this CPU model (   Consider compiler target flags as part of FCFLAGS and CFLAGS (ARCH file).
compiler_options_string

i.e. this is gfortran from GCC 9.3.0

And clang version 11.0.0, see
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=255647&view=logs&j=58ac6aab-c4bc-5de2-2894-98e408cc8ec9&t=933f325c-924e-533d-4d95-e93b5843ce8b&l=4989

The reason we're mixing these two is because they are the default c & fortran compilers on conda-forge.

I guess, other Conda packages are simply not doing that.

See e.g. Siesta
https://github.com/conda-forge/siesta-feedstock/blob/95f007deefefb38cd93dbed8ccfa82c924556239/recipe/meta.yaml#L46-L47

This doesn't make it right, of course.
We could try switching to gcc for the c compiler as well.

P.S. We do verify on CI that the regtests all pass. cp2k.ssmp --version simply does not seem to be tested anywhere; I will add it as an explicit test.

Edit: Reproduced issue on CI.
I'll see whether switching to gcc makes it go away

Edit: Unfortunately, there is no gcc for the osx platform :-( I.e. we'll need to make it work with clang here

[oschuett]

Actually, --version is used in the beginning of every regtest run to query the binary for its flags. However, I guess we're not checking the exit code :-/

[ltalirz]

I see... I opened #1299 on a similar issue of switching to a non-zero exit code for the regtests if any of the tests fail.
There @dev-zero mentioned this might be fixed by #770 but perhaps we should anyhow go ahead and adapt the regtest script?
This does not seem very hard to fix

[oschuett]

Do not wait for #770. I'm currently working on rewriting our do_regtest script in Python. Hopefully, I'll finish this in the next 1-2 months. Nevertheless, you can make those small changes to our existing script. There will certainly be a transition period before we can completely switch over to the new script.

[alas-go]

the bug has been reproduced again on centos 8.3 stream, with gcc 8.3.1, openmpi 4.0.5, python 3.6.8, and mkl 2020.4.
is it about compatibility of hardware ? i tried to install cp2k on several OS, like centos, fedora, and redhat, and the same bug has been reproduced. "make test" is ok but when mpirun or just run the cp2k.popt, the same error reproduced. I am using xeon 8273 and asrock motherboard (www.asrockrack.com)

[oschuett]

IIRC, the most likely cause was mixing compilers. So, I don't think there is anything we can do from CP2K's side.