[ITK-dev] ITK 4.8, castxml, and 32-bits Debian/gcc

[Brad King]

On 09/20/2015 11:03 PM, Steve M. Robbins wrote:
> /usr/share/castxml/clang/include/emmintrin.h:28:2: error: "SSE2 instruction set not enabled"
> #error "SSE2 instruction set not enabled"

CastXML (currently) needs to be invoked with a flag to enable
these instructions.  See below.

> The lines in emmintrin.h tests CPP symbol __SSE2__, which is not defined for 32-bit compiler in Debian.   Interestingly, the content of itkMathDetail.h near line 43 is:
> 
>     42  #if defined( ITK_HAVE_EMMINTRIN_H ) && !defined( __GCCXML__ )
>     43  #include <emmintrin.h> // sse 2 intrinsics
>     44  #endif /* ITK_HAVE_EMMINTRIN_H && ! __GCCXML__ */
> 
> First observation: prior to ITK 4.8, we used gccxml which
> defines __GCCXML__ and thus avoids including emmintrin.h.
> Now we are using castxml, which does not define this symbol.
> For compatibility, maybe it should?  Brad?

CastXML is not intended to be a 100% drop-in replacement for
gccxml but merely to make explicit porting relatively easy.
I do not think CastXML should pretend to be __GCCXML__ at
preprocessing time.  The above-quoted block in ITK could
be ported to work with CastXML.

> Secondly, I am slightly surprised that ITK should even need to
> guard against including things when __GCCXML __ is defined.
> I had naively assumed that gccxml should be seeing the same
> code as the regular parser.  Is this a work-around for some
> gccxml issues of the past or is it still needed?

It was a workaround for gccxml because its parser was hard-coded
to a specific architecture and had no way to simulate the
intrinsics of other architectures.  This should not be necessary
for CastXML because it really invokes its Clang compiler with
the proper target architecture.

> Thirdly, the emmintrin.h file that castxml uses presumably
> comes from clang and clearly depends on the symbol __SSE2__
> being defined.  However, the emmintrin.h shipped with GCC
> does not; does this represent an incompatibility between
> castxml and gcc?

I don't think so.  The emmintrin.h and similar headers are
part of the compiler's implementation details.  Such intrinsic
headers need to match the actual compiler, which within CastXML
is actually Clang regardless of what compiler is simulated.
That is why CastXML comes with copies of these headers from
the Clang against which it was built.

-----------------------------------------------------------------

I think the problem here is that CastXML needs to know when
to enable SSE as part of its target architecture configuration.
One could do that explicitly by adding '-msse' to the castxml
command-line right now.  That may get your build going.

It may also be possible for CastXML to configure itself when
given '--castxml-cc-gnu "(" gcc -msse ")"'.  For example,
the '-msse' flag causes gcc to add some predefined macros:

 #define __MMX__ 1
 #define __pentium_mmx__ 1
 #define __SSE__ 1

CastXML could recognize these to enable SSE internally.  One
challenge is that there are actually many variations of -msse
and we would need to figure out which one to use.

-Brad