1
私は、SunCC 5.11 - 5.13が../lnk/g3mangler.cc, line 825（SunCC 5.13からのメッセージ）で死に至る原因を特定しようとしています。コンパイル時の見た目は次のとおりです。マシンは第4世代のCore i5なので、マクロに対応する機能を持っています。`-std = XXX`を使用すると、g3mangler.ccでSunCCがクラッシュする原因は何ですか？
/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を切り替えるには、使用していたマクロです。
私がウェブで見つけられる唯一のレポートは、バグトラッカーからのものです。私は関数のすべてのコードを使い果たしてしまったので、アイデアはありません。
-std=XXXを使用すると、g3mangler.ccにSunCCコンパイラがクラッシュする原因は何ですか？どうすればそれを回避できますか？