使用 `-std=XXX` 时，什么导致 g3mangler.cc 中的 SunCC 崩溃？

Question

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?

Answer 1

From my experience on the old Sun forums, a failed assertion in one of the Solaris Studio components is always considered a compiler bug.

You'll likely be better served posting your issue to the Oracle forum for Solaris Studio .

You can also try different -compat= and -std= options. In particular, -std=sun03 may work for you (but it will not produce GNU C++-compatible binaries).