使用`-std=XXX`导致g3mangler.cc SunCC崩溃的原因是什么？
使用`-std=XXX`导致g3mangler.cc SunCC崩溃的原因是什么？
提问于 2016-09-12 09:19:47
我正在尝试确定是什么原因导致SunCC 5.11 - 5.13死于../lnk/g3mangler.cc, line 825 (来自SunCC 5.13的消息)。下面是它在编译过程中的样子。这台机器是第四代核心i5，因此它具有与宏相对应的功能。
/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是不可行的。
这是gcm.cpp:408。由于隔离的努力，它现在基本上被注释掉了。事实上，删除所有代码并保留一个空函数也证明了这一点：
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的宏。
我在网上能找到的唯一报告来自我们的bug追踪器。我没有想法，因为我已经用尽了函数中的所有代码。
在使用-std=XXX时，是什么原因导致SunCC编译器在g3mangler.cc中崩溃？我们该如何解决这个问题呢？
回答 1
Stack Overflow用户
发布于 2016-09-13 18:41:56
根据我在旧的Sun论坛上的经验，Solaris Studio组件中的一个失败的断言总是被认为是编译器错误。
将你的问题发布到the Oracle forum for Solaris Studio上可能会更好。
您还可以尝试不同的-compat=和-std=选项。特别是，-std=sun03可能适合您(但它不会生成与GNU C++兼容的二进制文件)。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/39442243
复制相关文章
相似问题
腾讯云开发者
