Compiling Eigen 3.3.4 (the latest release) with xlc++ 16.0.3 gives this error message: In file included from .../eigen/src/Eigen/Eigen/Core:376: .../eigen/src/Eigen/Eigen/src/Core/arch/AltiVec/PacketMath.h:1025:13: error: cannot initialize a variable of type 'Packet2bl' (aka 'Packet2ul') with an rvalue of type '__vector __bool unsigned long long' (vector of 2 'unsigned long long' values) ...mask = vec_cmpeq(reinterpret_cast(select), reinterpret_cast(p2l_ONE)); 1 error generated. However, compiling an earlier version of Eigen (3.2.10) has no such error. Can this error be fixed for compilation with Eigen? Now that the POWER9 Summit/Sierra supercomputer has gone online, the use of XLC for HPC codes is expected to increase dramatically. Thank you
Hi, I just got my Power9 Talos II board and will set it up in the next days. I will investigate the xlc issue, though this one looks similar to the CLANG issue, in the code line ~780 there is the code: #if EIGEN_COMP_CLANG typedef Packet2ul Packet2bl; #else typedef __vector __bool long Packet2bl; #endif Could you try adding a check for XLC in the first case?
(Passing on comments from one of my collaborators who looked at this) After inspection of PacketMath.h from eigen-3.3.4, the suggested code snippet is already there. Macro EIGEN_COMP_CLANG is defined for XLC compiler, along with EIGEN_COMP_IBM macro. (So I extended with an additional check for EIGEN_COMP_IBM, for consistency). The problem was with line 1025, namely I added a reinterpret cast to type Packet2bl: Packet2bl mask = reinterpret_cast<Packet2bl>( vec_cmpeq(reinterpret_cast<Packet2d>(select), reinterpret_cast<Packet2d>(p2l_ONE)); With this modification I was able to compile the code. I'm still curious why the problem did not arise with clang.
One of my colleagues has been able to synthesize a short test, which he expects is representative of the Eigen diagnostic: #include<altivec.h> void foo(__vector double v) { __vector bool long long r = vec_cmpeq(v, v); } Clang and g++ accept this because they allow lax vector conversions while the XL compiler does not. Clang emits a diagnostic as well if -fno-lax-vector-conversions is specified. The type of 'r' differs from the result type of the function. The diagnostic is valid and he would suggest the Eigen code be updated to improve portability. Regards, Nicole Trudeau, Customer Support for IBM Compilers
I applied the reinterpret_cast fix: https://bitbucket.org/eigen/eigen/commits/d2f8e1b572c0/ (default) https://bitbucket.org/eigen/eigen/commits/23eb37691f14/ (3.3)
Line 1057 in the default commit is missing a lost paren at the end of the line: https://bitbucket.org/eigen/eigen/commits/d2f8e1b572c0/#LEigen/src/Core/arch/AltiVec/PacketMath.hT1057
I submitted a PR to fix the typo. Can somebody please merge it? https://bitbucket.org/eigen/eigen/pull-requests/410/fix-typo-in-pbend-for-altivec/diff
.
Even with this PR in place, there is still in issue with XLC using the latest version of Eigen: /gpfs/gpfs_gl4_16mb/b7p319/b7p319ab/install/eigen-devel-2/include/eigen3/Eigen/src/Core/arch/AltiVec/PacketMath.h:945:71: error: 1540-0557 The asm operand does not match the specified constraint. __asm__ ("xvcmpgtdp %x0,%x2,%x1\n\txxsel %x0,%x1,%x2,%x0" : "=&wa" (ret) : "wa" (a), "wa" (b)); Note that the original patch does work on the latest release of Eigen, however, with above problem only appearing on the latest repository version of Eigen.
This issue is related to bug 1494.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1555.