Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: hash.cc doesn't build for 32-bit x86 (uses _mm_cvtsi128_si64 / _mm_extract_epi64)

Open Beginner friendly
#2,176 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
compilers

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from abseil/abseil-cpp

All issues in abseil/abseil-cpp

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.