将uint128_t位运算结果存入位域时是否存在GCC Bug？

问题代码 #

constexpr uint16_t KEY_BITS = 70;
constexpr unsigned __int128 KEY_BITS_MASK = (((unsigned __int128) 1) << KEY_BITS) - 1;

struct Entry
{
    unsigned __int128 left : 4;
    unsigned __int128 right : 4;
    unsigned __int128 key : KEY_BITS;
};

Entry data;

void print(unsigned __int128 a)
{
    std::cerr << std::bitset<16>(a >> 64) << std::bitset<64>(a) << std::endl;
}

void store(unsigned __int128 key, uint8_t left, uint8_t right)
{
    data.left = left;
    data.right = right;
    data.key = key & KEY_BITS_MASK;

    print(key & KEY_BITS_MASK);
    print(data.key);

    assert(data.key == (key & KEY_BITS_MASK));
}

问题现象 #

这段代码在GCC优化等级低于-O2时或Clang编译器中可正常运行，但开启GCC-O2优化后，增减print函数会改变程序行为——错误场景下，编译器会先将&运算的结果转换为64位整数，导致data.key与预期值不符，断言失败。

原因分析 #

这并非GCC的Bug，而是对C++位域类型的使用超出了标准规定，依赖了编译器的非标准扩展：

1. C++标准对位域类型的限制：标准明确规定，位域的类型只能是bool、有符号整数类型、无符号整数类型，或符合特定条件的枚举类型。unsigned __int128属于GCC提供的扩展整数类型，并非标准C++的一部分，其作为位域类型的行为属于实现定义行为，编译器没有义务保证跨优化等级的一致性。
2. GCC扩展的局限性：虽然GCC支持用__int128作为位域类型，但当位域总长度（此处为4+4+70=78位）超过64位时，在-O2优化的激进代码生成逻辑中，编译器可能错误地将位域存储视为64位单元处理，导致高位数据被截断，进而出现行为异常。
3. 优化策略的影响：增减print函数会改变编译器的优化路径，触发了这个非标准用法下的实现缺陷，但本质问题是代码依赖了未被标准覆盖的特性，属于自身用法的偏差。

解决建议 #

• 避免使用__int128作为位域类型，改用标准支持的类型组合实现需求，例如用两个uint64_t拆分存储长位域，或使用结构体拆分数据。
• 如果必须处理超过64位的位数据，可通过手动移位、位运算的方式模拟位域逻辑，确保行为符合标准规定。

内容的提问来源于stack exchange，提问作者mihovg93