问题描述
我试图确定是什么导致SunCC 5.11-5.13死于../lnk/g3mangler.cc, line 825(来自SunCC 5.13的消息).这是编译过程中的样子.该机器是第四代Core i5，因此具有与宏相对应的功能.
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.
我知道问题在所有编译器上均以-std=c++03出现，而在较新的编译器上均以-std=c++11出现.如果我省略-std=XXX，那么问题就消失了.告诉用户他们不能使用C ++ 03或C ++ 11是不可行的.
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.
这里是gcm.cpp:408.由于进行隔离，现在基本上已将其注释掉.实际上，删除所有代码并保留一个空函数也可以见证这一点:
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是我用来为编译器打开和关闭inline的宏.
MAYBE_INLINE is a macro I am using to toggle inline on and off for the compiler.
我在Web上只能找到的报告来自我们的错误跟踪器.我已经精疲力尽了，因为我已经用完了函数中的所有代码.
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.
是什么原因导致使用-std=XXX时SunCC编译器在g3mangler.cc中崩溃?我们如何解决呢?
What causes the SunCC compiler crash in g3mangler.cc when using -std=XXX? How can we work around it?
推荐答案
根据我在旧的Sun论坛上的经验，总是认为Solaris Studio组件之一中的断言失败是编译器错误.
From my experience on the old Sun forums, a failed assertion in one of the Solaris Studio components is always considered a compiler bug.
最好将问题发布到 Solaris Studio的Oracle论坛.
您还可以尝试使用其他 -compat= 和 -std= 选项.特别地，-std=sun03可能对您有用(但不会产生与GNU C ++兼容的二进制文件).
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).
这篇关于是什么原因导致在使用`-std = XXX`时g3mangler.cc中的SunCC崩溃?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！