PPC64 Python Wrapping: use of undeclared identifier '__builtin_altivec_vspltisw'

[thewtex]

Description

Python wrapping build on a ppc64le, POWER9, altivec supported system fails with.

[ 59%] Generating ../../itkFixedArray.xml
In file included from Wrapping/itkFixedArray.cxx:11:
In file included from Modules/Core/Common/include/itkSymmetricSecondRankTensor.h:29:
In file included from Modules/Core/Common/include/itkSymmetricEigenAnalysis.h:23:
In file included from Modules/ThirdParty/Eigen3/src/itkeigen/Eigen/Eigenvalues:11:
In file included from Modules/ThirdParty/Eigen3/src/itkeigen/Eigen/Core:399:
 Modules/ThirdParty/Eigen3/src/itkeigen/Eigen/src/Core/arch/AltiVec/PacketMath.h:70:8: error: use of undeclared identifier '__builtin_altivec_vspltisw'
 static _EIGEN_DECLARE_CONST_FAST_Packet4f(ZERO, 0); //{ 0.0, 0.0, 0.0, 0.0}

Steps to Reproduce

Enable Python wrapping on a POWER9 system running CentOS 7.6.1810 AltArch 4.14.0-115.6.1.el7a.ppc64le.

Compiler: c++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

Expected behavior

Build should succeed.

Actual behavior

Build fails in CastXML parsing for itkFixedArray.cxx.

Reproducibility

100%

Versions

ITK Git master 687c49176ba97fbbe805fc468bd96ec36b46ffc0

Environment

Compiler: c++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) Enable Python wrapping on a POWER9 system running CentOS 7.6.1810 AltArch 4.14.0-115.6.1.el7a.ppc64le.

Additional Information

We should bump ITK's CastXML and the LLVM / Clang versions, then address this error.

[malaterre]

Is there a way to have the exact compilation line ?

[thewtex]

voila:

cd /home/thewtex/ITK-build/Wrapping/Modules/ITKCommon && ../../Generators/CastXML/castxml/bin/castxml -o /home/thewtex/ITK-build/Wrapping/itkFixedArray.xml --castxml-gccxml --castxml-start _wrapping_ --castxml-cc-gnu "(" /usr/bin/c++ -Wall -Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -funit-at-a-time -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual-Wstrict-null-sentinel -Wno-array-bounds -Wno-array-bounds -std=c++11 ")" -w -c @/home/thewtex/ITK-build/Wrapping/ITKCommon.castxml.inc /home/thewtex/ITK-build/Wrapping/itkFixedArray.cxx

[malaterre]

@thewtex So this means the warning is triggered by castxml which is built upon clang. So I believe the following section applies:

• http://clang.llvm.org/compatibility.html#vector_builtins

Maybe @bradking has something portable that works on arch !x86.

[bradking]

I've reproduced this in a simple example:

$ cat altivec.cpp 
#include <altivec.h>
static __vector int start = vec_splat_s32(0);
$ castxml --castxml-gccxml --castxml-start start --castxml-cc-gnu c++ -w altivec.cpp
altivec.cpp:2:29: error: use of undeclared identifier '__builtin_altivec_vspltisw'
static __vector int start = vec_splat_s32(0);

Leaving out --castxml-cc-gnu c++ avoids the problem (but won't work for ITK's use case). I'll dig further.

[bradking]

Please update ITK's castxml to get the fix in CastXML/CastXML#145.

After that I needed only a small patch to some compiler-specific code in Eign to get the ITKCommonCastXML target to build.

Patch for Eigen in ITK

```patch diff --git a/Modules/ThirdParty/Eigen3/src/itkeigen/Eigen/src/Core/arch/AltiVec/PacketMath.h b/Modules/ThirdParty/Eigen3/src/itkeigen/Eigen/src/Core/arch/AltiVec/PacketMath.h index 08a27d1530..e8b1f48cad 100644 --- a/Modules/ThirdParty/Eigen3/src/itkeigen/Eigen/src/Core/arch/AltiVec/PacketMath.h +++ b/Modules/ThirdParty/Eigen3/src/itkeigen/Eigen/src/Core/arch/AltiVec/PacketMath.h @@ -774,7 +774,7 @@ template<> EIGEN_STRONG_INLINE Packet4f pblend(const Selector<4>& ifPacket, cons typedef __vector double Packet2d; typedef __vector unsigned long long Packet2ul; typedef __vector long long Packet2l; -#if EIGEN_COMP_CLANG +#if EIGEN_COMP_CLANG || defined(__castxml__) typedef Packet2ul Packet2bl; #else typedef __vector __bool long Packet2bl; ```

[thewtex]

Thanks @bradking !

I will work on the CastXML bump in ITK.

[thewtex]

The build still fails.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.