[Bug]: hash.cc doesn't build for 32-bit x86 (uses _mm_cvtsi128_si64 / _mm_extract_epi64)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
Research direction
Start in absl/hash/internal/hash.cc at the SSE4.2 and AES preprocessor guard around the reported intrinsics. Compare the guard with absl/crc/internal/crc32_x86_arm_combined_simd.h, then verify that the 32-bit command g++ -m32 -msse4.2 -maes -std=c++17 -I. -c absl/hash/internal/hash.cc succeeds while the 64-bit build remains valid.
Written by the indexing model from the issue text.
Description
Describe the issue
Describe the issue
Building abseil for a 32-bit x86 target fails in absl/hash/internal/hash.cc:
absl/hash/internal/hash.cc:57:36: error: '_mm_cvtsi128_si64' was not declared in this scope; did you mean '_mm_cvtsi32_si64'?
absl/hash/internal/hash.cc:58:36: error: '_mm_extract_epi64' was not declared in this scope; did you mean '_mm_extract_epi8'?
Both intrinsics are x86-64 only, but the AES SIMD path that uses them is
gated only on SSE4.2 + AES:
#elif defined(__SSE4_2__) && defined(__AES__)
#define ABSL_AES_INTERNAL_HAVE_X86_SIMD
#endif
My 32-bit toolchain reports SSE4.2 and AES, so the macro gets defined and the
code tries to use 64-bit intrinsics that don't exist on i386/i686.
The CRC code already guards against exactly this (it requires x86_64 for
its x86 SIMD path); the hash AES SIMD path just doesn't have the same check.
master has it too (same intrinsics show up around lines 115 and 119 under the
same macro).
Adding a 64-bit check to the guard fixes it for me:
#elif defined(__SSE4_2__) && defined(__AES__) && \
(defined(__x86_64__) || defined(_M_X64))
Steps to reproduce the problem
From the abseil source root:
g++ -m32 -msse4.2 -maes -std=c++17 -I. -c absl/hash/internal/hash.cc
Fails at hash.cc:57/58. A 64-bit build (-m64) of the same file is fine. Hit it
originally cross-building the 32-bit multilib of abseil in Yocto
What version of Abseil are you using?
20260107.1 (master looks affected too).
What operating system and version are you using?
Linux, cross-compiling a 32-bit i686 target on x86-64.
What compiler and version are you using?
gcc 15.3.0 (i686 cross).
What build system are you using?
cmake, but it's not build-system specific - it's the preprocessor guard.
Additional context
_mm_cvtsi128_si64 and _mm_extract_epi64 are both documented as 64-bit mode
only in the Intel intrinsics guide.
The CRC code already handles this correctly. absl/crc/internal/crc32_x86_arm_combined_simd.h
gates its x86 SIMD path on x86_64 specifically for this reason, with the
comment:
// This implementation requires 64-bit CRC instructions (part of SSE 4.2) and
// PCLMULQDQ instructions. 32-bit builds with SSE 4.2 do exist, so the
// __x86_64__ condition is necessary.
#if defined(__x86_64__) && defined(__SSE4_2__) && defined(__PCLMUL__)
The hash AES SIMD path just needs the same x86_64 guard - it's the same
"32-bit build with SSE4.2 does exist" situation, using the same 64-bit-only
intrinsics.
- Dominant language
- C++
- Stars
- 18.1k
- Forks
- 3.2k
- Avg merge
- 12h 35m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from abseil/abseil-cpp
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
abseil/abseil-cpp#2153 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
abseil/abseil-cpp#2140 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
abseil/abseil-cpp#2027 · 2 reactions ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
abseil/abseil-cpp#1875 · 2 reactions ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
abseil/abseil-cpp#1824 · 1 comment ·
All issues in abseil/abseil-cpp
Similar issues
-
bug build
Difficulty 1/5 Under an hour Newbie friendliness 91/100
facebookincubator/velox#19194 ·
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW Openfuzz
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ClickHouse/ClickHouse#122114 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
module/agent platform/macos type/bug/regression
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
enhancement PyCDE
Difficulty 2/5 1-3 hours Newbie friendliness 78/100