ABINIT Discussion Forums

Posted: **Thu Jul 02, 2015 1:46 am**

Dear all,

This issue has been discussed here and there on the forum, but I find no satisfactory answer to the problem.

Upon compiling Abinit (libxc+netcdf) with gcc-4.9 and openmpi on a Macbook Pro (Intel Core i7 processor), the build fails with a series of errors like

Code: Select all

/var/folders/_0/7xntnmw90qzd28wc1b3hxz140000gn/T//cc19FSRv.s:67932:no such instruction: `vmovss %xmm0, 8(%rsp)'

This kind of error is traced back to the assembler, which does not supports AVX instructions, and is incompatible with the processor in this respect.

It was suggested to use gcc of MacPorts (instead of Homebrew), but that does not solve the problem. Other suggestions out there were to use specific compilation flags, such as ‘-Wa,-q’ or ‘-msse4.2’, which give several warnings like

Code: Select all

/opt/local/bin/ranlib: file: lib41_xc_lowlevel.a(interfaces_41_xc_lowlevel.o) has no symbols

and result in a compiled code that fails to run.

Does anyone have a solution?

Posted: **Thu Jul 02, 2015 7:54 pm**

The problem is definitely with the Macports/Homebrew/whatever versions of GCC, not with Abinit.

Macports forums users wrote:... after some search, the Apple assembler cannot handle AVX instructions, which is why it fails. Clang seems to be the only compiler able to deal with these instructions. The attached Portfile version should compile in all cases, by disabling avx for gcc compilers, but at the cost of performance, and adding a clang version which hopefully could compile avx instructions. I couldn't test it though, as my processor is too old to support these instructions ...

In summary:

use Clang if your processors support AVX;
disable AVX instructions when compiling with GCC if your processors don't support AVX.

Posted: **Fri Jul 03, 2015 2:39 am**

Indeed, the problem lies with the gcc versions I'm able to get on my Mac. However, all the methods I have found elsewhere to circumvent this problem seem not to work with Abinit...

As for the solutions you propose,

Using Clang compilers
The clang gcc compilers provided by Apple do not include gfortran, so the problem of finding a good fortran compiler remains. As an alternative I have tried apple-gcc42 and llvm-gcc28, but neither fortran compiler get past the configure step, giving me:

Code: Select all

Fortran compiler does not provide iso_c_binding module. Use a more recent version or a different compiler

The phase space of compilers being very large, I would be happy to know of a working version of gcc.

Disabling AVX instructions
This seems to be the most sensible option, and I have been looking for a way to do this. I think this is the purpose of the compilation flags mentioned above, but those do not work for me. If anyone has some knowledge on that, please share it!

Posted: **Fri Jul 03, 2015 11:10 pm**

Hello Gabi,

I have new servers for the test farm with new Haswell processors : Xeon(R) CPU E5-2670 v3 @ 2.30GHz

I have also a MacPro under Yosemite with cpu with AVX capability

Code: Select all

sysctl -n machdep.cpu.brand_string
Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz

some experiences/ascertainments :

1) a bot under CentOS 6.6 with gcc 5.1 ( I have compiled ),
and with the standard packages ( specially binutils 2.22) , I had as many messages as you had … ( with "-O2 -mtune=native -march=native" )

I must install the latest version of binutils == 2.24 ( which contains as and ld commands ) to resolve the problem
( then, gcc 5.1 generated assembler codes compatible with avx but the "standard" binutils can not resolve it ! )

2) with MacPorts, I have installed these packages :

Code: Select all

 port installed | grep active | egrep  "gcc49|netcdf|hdf5|fft|binutils"
  atlas @3.10.2_1+gcc49 (active)
  binutils @2.24_0 (active)
  etsf_io @1.0.4_2+gcc49 (active)
  fftw-3 @3.3.4_1+gfortran (active)
  fftw-3-single @3.3.4_1+gfortran (active)
  gcc49 @4.9.2_1 (active)
  hdf5 @1.8.14_0+cxx+gcc49 (active)
  netcdf @4.3.3.1_0+dap+gcc49+netcdf4 (active)
  netcdf-fortran @4.4.2_0+gcc49 (active)
  openmpi-gcc49 @1.7.5_3+fortran (active)

If I compile ABINIT with "FCFLAGS = -O2 -g" , everything is OK ! ( compilation and tests )
if I compile ABINIT with FCFLAGS="-O2 -g -mtune=native -march=native" , same problems with compilation

Code: Select all

/var/folders/17/r4jwx8ls2vqc8vc851ww5hjh0000gr/T//ccBMqjw7.s:17:no such instruction: `vmovsd 8(%rdi), %xmm5'
…

then , it seems that the 'as' command from MacPorts ( binutils 2.24) doesn't resolve the assembler code specific to avx instructions !?!

to be continued,

cheers

Posted: **Fri Jul 03, 2015 11:24 pm**

some additional informations...

http://comments.gmane.org/gmane.os.appl ... user/34339
https://trac.macports.org/ticket/37846

jmb

Posted: **Wed Jul 08, 2015 6:47 am**

Hi Jean-Mi,

1) Concerning the use of binutils, the defaut version (2.24) installed by MacPorts does not contain as nor ld. Can you force the installation of these components? The same goes for Homebrew’s binutil (2.25). Rumour has it that these can not be built on Darwin. My own attempts to build as and ld break my compilers to fare-thee-well !

2) Using "FCFLAGS = -O2 -g" and building all fallbacks results in segfaults for most of the tests:

Code: Select all

Suite   failed  passed  succeeded  skipped  disabled  run_etime  tot_etime
v1          52       0         24        0         0      63.60      65.93

3) Using "FCFLAGS = -O2 -g" and building only libxc, while relying on Homebew versions of lapack, fftw, hd5, netcdf, etsf_io,
create several ‘no symbols’ warnings and ends with

Code: Select all

Undefined symbols for architecture x86_64:
  "_xc_f90_family_from_id_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_init in lib41_xc_lowlevel.a(m_libxc_functionals.o)
      _invars2_ in lib57_iovars.a(invars2.o)
  "_xc_f90_func_end_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_end in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_func_init_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_init in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_gga_exc_vxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_gga_fxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_gga_vxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_info_flags_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
      ___libxc_functionals_MOD_libxc_functionals_init in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_info_kind_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_info_name_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_fullname in lib41_xc_lowlevel.a(m_libxc_functionals.o)
      ___libxc_functionals_MOD_libxc_functionals_init in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_info_refs_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_init in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_lda_c_xalpha_set_par_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_init in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_lda_exc_vxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_lda_fxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_lda_kxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_lda_vxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_mgga_exc_vxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_mgga_vxc_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
  "_xc_f90_mgga_x_tb09_set_par_", referenced from:
      ___libxc_functionals_MOD_libxc_functionals_getvxc in lib41_xc_lowlevel.a(m_libxc_functionals.o)
ld: symbol(s) not found for architecture x86_64

Maybe that last point could be worked around. After all, the initial problem with AVX instructions seems to pop up during the compilation of the fallbacks.

Posted: **Wed Jul 08, 2015 7:06 pm**

1) You likely have problems at link-time due to calls to the wrong version of ld. Things are a bit messy on MacOSX regarding the use of ld and ld64. The following links may give you useful information to further understand the issue:
* https://developer.apple.com/library/mac ... lding.html
* http://stackoverflow.com/questions/1566 ... -apple-dar

2) The unresolved symbols you get might come from LibXC being compiled in 32 bits while you expect 64 bits.

Posted: **Fri Jul 10, 2015 10:33 pm**

So I finally managed to solve all the various problems (because platform-specific questions means that we are dealing with several problems at once). Here are my instructions to build abinit on a macbook with gcc:

1) Specify “FCFLAGS=‘-O2 -g’ . This is to avoid having -march=native in the flags, which cause the AVX instructions to be used and makes the assembler lose its mind.

2) Build netcdf, etsf_io and libxc altogether, because that’s just the way it is. And one should not forget to specify the cpp, and also make a symbolic link named “cpp” because libxc wants a cpp actually named “cpp”…

3) Specify with_linalg_flavor='netlib-fallback', because otherwise the build system decides to build nothing for linalg, creating an empty linalg library if lapack cannot be found. That is really a weird behaviour from the build system. It would be nice to have a warning in those cases.

Thanks a lot Yan and Jean-Michel for helping me figure this out

Posted: **Sat Jul 11, 2015 8:19 pm**

Hello Gabi,

with MacPorts under Yosemite and with AVX-enabled processor, I confirm that
with this .ac file, it works…. :

Code: Select all

CFLAGS="-O2 -g"
CXXFLAGS="-O2 -g"
FCFLAGS="-O2 -g -ffree-line-length-none"
enable_mpi="yes"
enable_mpi_io="yes"
with_mpi_prefix="/opt/local"
with_trio_flavor="netcdf+etsf_io"
with_etsf_io_incs="-I/opt/local/include/gcc"
with_netcdf_incs="-I/opt/local/include"
with_netcdf_libs="-L/opt/local/lib -lnetcdf -lnetcdff"
with_fft_flavor="fftw3"
with_fft_libs="-L/opt/local/lib -lfftw3 -lfftw3f"
with_linalg_flavor="atlas"
with_linalg_incs="-I/opt/local/include"
with_linalg_libs="-L/opt/local/lib -llapack -lf77blas -lcblas -latlas"
with_dft_flavor="libxc"
enable_clib="yes"
enable_memory_profiling="no"
enable_openmp="no"
enable_maintainer_checks="no"

then , I use the ports ( my previous post) : etsf_io, atlas, netcdf but, not libxc…

Can you confirm that this recipe is working for you ?

thanks

jmb

Posted: **Mon Jul 13, 2015 7:07 pm**

That recipe doesn't work for me. I get the same Undefined symbols errors as mentioned above.

I used a fresh installation of the following package with homebrew:

Code: Select all

gcc: stable 5.1.0 (bottled)
open-mpi: stable 1.8.4 (bottled)
fftw: stable 3.3.4 (bottled)
homebrew/dupes/lapack: stable 3.5.0 (bottled)
homebrew/science/hdf5: stable 1.8.14 (bottled)
homebrew/science/netcdf: stable 4.3.3.1 (bottled)
homebrew/science/etsf_io: stable 1.0.4 (bottled)

And my .ac file looks like this

Code: Select all

enable_mpi="yes"
enable_mpi_io="yes"
with_mpi_prefix="/usr/local"
FCFLAGS=" -O2 -g -ffree-line-length-none"
CFLAGS="  -O2 -g "
CCFLAGS=" -O2 -g "
CXXFLAGS="-O2 -g "

with_dft_flavor="libxc"
with_trio_flavor="etsf_io+netcdf"

with_fft_flavor="fftw3"
with_fft_incs="-I/usr/local/include/"
with_fft_libs="-L/usr/local/lib/ -lfftw3.3 -lfftw3f.3 -lfftw3l.3"

with_linalg_flavor="custom"
with_linalg_incs="-I/usr/local/Cellar/lapack/3.5.0/include/"
with_linalg_libs="-L/usr/local/Cellar/lapack/3.5.0/lib/ -lblas -llapack"

with_netcdf_incs="-I/usr/local/include"
with_netcdf_libs="-L/usr/local/lib -lnetcdf -lnetcdff "

with_etsf_io_incs="-I/usr/local/Cellar/etsf_io/1.0.4_2/include/"
with_etsf_io_libs="-L/usr/local/Cellar/etsf_io/1.0.4_2/lib/ -letsf_io -letsf_io_low_level -letsf_io_utils"

enable_clib="yes"
enable_memory_profiling="no"
enable_openmp="no"
enable_maintainer_checks="no"
enable_gw_dpc="yes"
enable_64bit_flags="yes"

I tried both with and without enable_64bit_flags, and I get the same result. Yan suggested that it might be caused by libxc being compiled in with 32bits but I see a "-m64" flag in the compilation of libxc.

I conclude that netcdf and/or etsf_io were not compiled in the same way as libxc...

ABINIT Discussion Forums

gcc on a Macbook: living with an AVX-enabled processor

gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor [SOLVED]

Re: gcc on a Macbook: living with an AVX-enabled processor

Re: gcc on a Macbook: living with an AVX-enabled processor