Problems installing on Linux Intel Cluster

[Brandon Groth]

Hello,

I am having trouble getting the test script from the installation page to compile on icc 16.0. Here are my current problems:

1. Within blaze/util/Limits.h and blaze/math/Accuracy.h, I am getting tons of constexpr compiler errors from lines like:

.../blaze/util/Limits.h(169): error #3377: constexpr function return is non-constant static inline constexpr signed char ninf() { return std::numeric_limits<signed char>::min(); }

Does Intel support these expressions as of icc 16.0?

2. I am getting an error with linking the Boost library. I don't have root privileges, so I had to install it in my own directory. In setting up the blaze/Configfile, there was a lack of direction in the exact files you were after.

Current error: /home/bmgroth/blas/blaze/blaze/math/blas/axpy.h(43): catastrophic error: cannot open source file "boost/cast.hpp" #include <boost/cast.hpp>

Current Configfile:

BOOST_INCLUDE_PATH="/home/bmgroth/blas/boost_1_62_0/boost" BOOST_LIBRARY_PATH="/home/bmgroth/blas/boost_1_62_0/libs" BOOST_SYSTEM_LIBRARY="/home/bmgroth/blas/boost_1_62_0/boost/system" BOOST_THREAD_LIBRARY="/home/bmgroth/blas/boost_1_62_0/boost/thread"

Were these the directories that you were expecting? I couldn't find any info as to which system and thread libraries you may have been referencing.

[Klaus Iglberger]

Hi Brandon!

Intel 16 Issue

Unfortunately we cannot reproduce your problem with the Intel compiler. In our case all tests compile flawlessly with Intel-16.1. Your problem appears to be a configuration problem. Please make sure that the Intel compiler uses the library of a C++14 gcc compiler.

Building the Tests

The Configfile for the tests expects the Boost include path such that including for instance #include <boost/cast.hpp> works. You probably have to remove the boost subdirectory:

BOOST_INCLUDE_PATH="/home/bmgroth/blas/boost_1_62_0" 

The BOOST_SYSTEM_LIBRARY and BOOST_THREAD_LIBRARY switches only expect the name of the system and thread libraries, respectively. In most cases, these libraries are called boost_system and boost_thread, but the names may differ. Please see in your /home/bmgroth/blas/boost_1_62_0/libs directory how these two libraries are named and if they are named differently, please only specify the name (e.g. boost_system-mt):

BOOST_SYSTEM_LIBRARY="boost_system-mt"
BOOST_THREAD_LIBRARY="boost_thread-mt"

I hope this helps,

Best regards,

Klaus!

[Brandon Groth]

Hello again Klaus,

I just heard back from a system admin, which they revealed that icc 16.0 doesn't support the use of "relaxed" constexpr rules that are used in your Limits and Accuracy files. As of icc 17.0, these relaxed rules have been resolved. Here are the links:

Past Intel compilers support for c++14 (Extended constexpr is not supported): https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler

Release notes for icc 17.0 (search for constexpr): https://software.intel.com/en-us/articles/intel-c-compiler-170-for-linux-release-notes-for-intel-parallel-studio-xe-2017

Unfortunately, my cluster that I am on only has access to icc 16.0, because our cluster license has expired with Intel. Unless there is some kind of work around to hide the relaxed rules, I will have to move machines just to test Blaze.

Anyways, thank you for the response!

[Klaus Iglberger]

Hi Brandon!

Thanks a lot for the links. However, just to clarify my point, at this point Blaze does not rely on the relaxed constexpr rules and therefore you should be able to compile Blaze with icc 16.0. In your case it seems to be a problem with the gcc library that is used. As an example, consider the implementation of the Limits class (from your initial position, <Limits.h>, line 169):

template<>
struct Limits<signed char>
{
   ...
   static inline constexpr signed char ninf() { return std::numeric_limits<signed char>::min(); }
   ...
};

This implementation is based on the C++11 constexpr rules. If it doesn't compile, then the std::numeric_limits implementation is not using constexpr. This can only happen if a pre-C++11 standard library is used.

I hope this helps to resolve the problem.

Best regards,

Klaus!