Closed wcwitt closed 2 years ago
This must be because of my md5sum commit. Which intel compiler did you use?
Can you please submit some more details? With the 2019 intel suite it compiles fine for me.
Sure - just ran through it again:
git clone --recursive https://github.com/libAtoms/QUIP.git
cd QUIP
export QUIP_ARCH=linux_x86_64_ifort_icc
make config
[lapack/blas: -L${MKLROOT}/lib/intel64 -lmkl_rt -lpthread -lm -ldl]
[n to preconditioned minimisation]
[y to GAP]
make
with
$ ifort -v
ifort version 19.1.2.254
$ icc -v
icc version 19.1.2.254 (gcc version 4.8.5 compatibility)
The trouble for me does begin in the neighborhood of the md5
stuff
icc -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/wcw28/.conda/envs/calphy2/include -fPIC -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/fox/objs.linux_x86_64_ifort_icc/finclude -O3 -g -traceback -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,6f2ad16d1"' -D'GAP_VERSION=1651824457' -D'QUIP_ARCH="linux_x86_64_ifort_icc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_GAP -DHAVE_QR -fPIC -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/fox/objs.linux_x86_64_ifort_icc/finclude -O3 -g -traceback -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,6f2ad16d1-dirty"' -D'GAP_VERSION=1651824457' -D'QUIP_ARCH="linux_x86_64_ifort_icc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_GAP -DHAVE_QR -c /home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms/md5.c
icc: command line warning #10006: ignoring unknown option '-fno-plt'
icc: warning #10193: -vec is default; use -x and -ax to configure vectorization
icc -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/wcw28/.conda/envs/calphy2/include -fPIC -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/fox/objs.linux_x86_64_ifort_icc/finclude -O3 -g -traceback -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,6f2ad16d1"' -D'GAP_VERSION=1651824457' -D'QUIP_ARCH="linux_x86_64_ifort_icc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_GAP -DHAVE_QR -fPIC -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms -I/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/fox/objs.linux_x86_64_ifort_icc/finclude -O3 -g -traceback -DDUMP_CORE_ON_ABORT -DGETARG_F2003 -DFORTRAN_UNDERSCORE -D'GIT_VERSION="https://github.com/libAtoms/QUIP.git,6f2ad16d1-dirty"' -D'GAP_VERSION=1651824457' -D'QUIP_ARCH="linux_x86_64_ifort_icc"' -D'SIZEOF_FORTRAN_T=2' -DHAVE_GAP -DHAVE_QR -c /home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms/cutil.c
icc: command line warning #10006: ignoring unknown option '-fno-plt'
icc: warning #10193: -vec is default; use -x and -ax to configure vectorization
/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms/cutil.c(170): error: expected an expression
for(int i = 0; i < 16; i++)
^
/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms/cutil.c(170): error: identifier "i" is undefined
for(int i = 0; i < 16; i++)
^
/home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms/cutil.c(273): warning #810: conversion from "void *" to "int" may lose significant bits
return ((int) p);
^
compilation aborted for /home/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/src/libAtoms/cutil.c (code 2)
make[1]: *** [cutil.o] Error 2
make[1]: Leaving directory `/rds/user/wcw28/hpc-work/nonhydrostatic/codes/cclake/test/QUIP/build/linux_x86_64_ifort_icc'
make: *** [libAtoms] Error 2
Looks like moving the definition of int i
outside the scope of the for loop and cleaning up the case should fix this.
This is why it would be good to have Intel compilers in the CI, hence #329, but unfortunately we didn't get it working.
Yes - the intel compiler should really interpret the code according to the 11 (or even 99) standard, which allows this syntax. But I agree with James that it's best moving the declaration outside, hence the pull request. @wcwitt if you can confirm that it compiles for you, I'll close this issue.
https://github.com/libAtoms/QUIP/pull/442 compiles for me. Thanks. I confess I thought it must be something else.
I wasn't able to build with Intel today, failing at
cutil.c
. I don't recall the full error (sorry), but it worked again after I reverted to aadb4a0a10b90601735c9a1439e8f04bd8abb70b.