I'm trying to determine what is causing SunCC 5.11 - 5.13 to die with ../lnk/g3mangler.cc, line 825 (message from SunCC 5.13). Here's what it looks like during a compile. The machine is a 4th gen Core i5, so its got the features which correspond to the macros.
/opt/solarisstudio12.4/bin/CC -DDEBUG -g3 -O0 -std=c++03 -D__SSE2__ -D__SSE3__ -D__SSSE3__
-D__SSE4_1__ -D__SSE4_2__ -D__AES__ -D__PCLMUL__ -D__RDRND__ -D__AVX__ -xarch=avx
-m64 -native -KPIC -template=no%extdef -w -erroff=wvarhidemem -erroff=voidretw -c gcm.cpp
>> Assertion: (../lnk/g3mangler.cc, line 825)
while processing gcm.cpp at line 408.
I know the problem surfaces with -std=c++03 on all the compilers, and -std=c++11 on the newer compilers. If I omit -std=XXX, then the problem goes away. Telling users they cannot use C++03 or C++11 is not viable.
Here is gcm.cpp:408. Its basically commented out now due to efforts to isolate. In fact, deleting all the code and leaving an empty function witnesses it, too:
MAYBE_INLINE void GCM_Base::ReverseHashBufferIfNeeded()
{
#if BOOL_AESNI_INTRINSICS_AVAILABLE
// if (HasCLMUL())
{
// __m128i &x = *(__m128i *)(void *)HashBuffer();
// x = _mm_shuffle_epi8(x, s_clmulConstants[1]);
}
#elif BOOL_ARM_CRYPTO_INTRINSICS_AVAILABLE
if (HasPMULL())
{
if (GetNativeByteOrder() != BIG_ENDIAN_ORDER)
{
const uint8x16_t x = vrev64q_u8(vld1q_u8(HashBuffer()));
vst1q_u8(HashBuffer(), (uint8x16_t)vcombine_u64(vget_high_u64((uint64x2_t)x), vget_low_u64((uint64x2_t)x)));
}
}
#endif
}
MAYBE_INLINE is a macro I am using to toggle inline on and off for the compiler.
The only reports I can find on the web are from our bug tracker. I'm out of ideas since I've exhausted all the code in the function.
What causes the SunCC compiler crash in g3mangler.cc when using -std=XXX? How can we work around it?
