Compilation failure with g++-4.8

[galexv]

The compilation fails with g++-4.8 and Boost 1.60, but seems to work fine with g++-5.4 and Boost v. 1.58
Although it has been triggered by the update of ALPSCore, it does not seem to be caused by the ALPSCore code. It might be due to a specific combination of Boost 1.60, g++ 4.8 and Eigen 3.3.4 ...

The error is:

In file included from /usr/local/eigen/eigen_3.3.4/Eigen/Core:390:0,
from /usr/local/eigen/eigen_3.3.4/Eigen/Dense:1,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/CT-HYB/src/sliding_window/../model/model.hpp:18,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/CT-HYB/src/sliding_window/sliding_window.hpp:8,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/CT-HYB/src/sliding_window/sliding_window.cpp:1:
/usr/local/eigen/eigen_3.3.4/Eigen/src/Core/arch/CUDA/Half.h:481:8: error: specialization of ‘std::numeric_limitsEigen::half’ after instantiation
struct numeric_limitsEigen::half {
^
/usr/local/eigen/eigen_3.3.4/Eigen/src/Core/arch/CUDA/Half.h:481:8: error: redefinition of ‘struct std::numeric_limitsEigen::half’
In file included from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/boost_1_60_0_b1/include/boost/limits.hpp:19:0,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/boost_1_60_0_b1/include/boost/multi_array/index_range.hpp:18,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/boost_1_60_0_b1/include/boost/multi_array/base.hpp:23,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/boost_1_60_0_b1/include/boost/multi_array.hpp:21,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/CT-HYB/src/sliding_window/sliding_window.hpp:4,
from /home/galexv/Work/UMich/ALPSCore/ALPSCore_apps/CT-HYB/src/sliding_window/sliding_window.cpp:1:
/usr/include/c++/4.8/limits:304:12: error: previous definition of ‘struct std::numeric_limitsEigen::half’
struct numeric_limits : public __numeric_limits_base
^

[shinaoka]

Thank you. It seems bit odd.
The struct Eigen::half is defined at line 76 of Half.h.
But I do not understand why this causes a compilation error.
Do you think there is a bug in gcc4.8?

[shinaoka]

What is the minor version of gcc4.8?

[galexv]

I have looked into it a little bit more, and managed to shrink the existing CT-HYB code to the following minimal example that still shows the error:

#include <complex>
#include <boost/multiprecision/cpp_bin_float.hpp>
typedef boost::multiprecision::cpp_bin_float_quad EXTENDED_REAL;

template<typename T>
class wcomplex;
typedef wcomplex<EXTENDED_REAL> EXTENDED_COMPLEX;

// (1) Commenting this out eliminates the error:
template<typename T>
wcomplex<T>
operator*(EXTENDED_REAL z, const wcomplex<T> &w) {
  return w * z;
}

// (2) Moving this to the 1st line eliminates the error:
#include <Eigen/Dense>

As the comments indicate, commenting out the function template definition (1) OR moving the #include (2) makes the error disappear.

Compilation script:

CC=/usr/bin/g++-5
BOOST_INC=/usr/include
EIGEN_INC=/usr/local/eigen/eigen_3.3.4

$CC -I$BOOST_INC -I$EIGEN_INC -o min_test.cpp.o -c min_test.cpp

A funny thing is that this minimal example shows the error both with g++-4.8.5 and g++-5.4.0, and with Boost 1.58, 1.63 and 1.65.1 (which is the latest), as well as with Eigen 3.3.4 and with the latest unstable Eigen3.

It does not show the error with Eigen 3.3.1.

As a proof of concept, i copied sliding_window.cpp and all its dependencies to a separate directory tree, verified that i see the compilation error, then commented out all #include <Eigen/....> and added the Eigen includes to the top of sliding_window.cpp. Then the code compiled without error. Because there are #pragma once in proper places, it's in fact sufficient to simply move the Eigen includes to the top of sliding_window.cpp without commenting anything out --- then the code compiles too.

I guess it's a viable workaround to include the Eigen headers only once and before any Boost headers; the open question is what's going on and whether it's Eigen, Boost, or C++ bug.

[galexv]

I have pushed the workaround and also tweaked Jenkins task configuration a bit to address occasional running out of memory. The code compiles now.

[shinaoka]

Thank you!

BTW, I implemented our own complex number class for multi precision floating points because instantiating the template std::complex for any other types than float, double, long double is unspecified.