为何编译器可优化掉带原地修改的std::for_each循环？

问题重现 #

以下代码在低优化级别（如Clang 15 -O0、GCC 12 -O0/-O1）下，两个函数均返回预期值65537（即2^16 + 2^0），但在更高优化级别下，incrementWithReference函数返回0，相关修改代码被编译器移除：

#include <iostream>
#include <algorithm>
#include <cstdint>

uint32_t incrementWithReference() {
    uint32_t input = 0;

    auto* begin = reinterpret_cast<uint16_t*>(&input);
    auto* end = begin + 2;
    //std::cout << "[DEBUG: begin = " << *begin << "] ";
    std::for_each(begin, end, [](uint16_t &n){ ++n; });

    return input;
}

uint32_t incrementWithCopy() {
    uint32_t input = 0;
    uint32_t output;

    auto* begin = reinterpret_cast<uint16_t*>(&input);
    auto* end = begin + 2;
    auto* dest = reinterpret_cast<uint16_t*>(&output);
    std::transform(begin, end, dest, [](auto n) { return ++n;});

    return output;
}

int main() {
   std::cout << "withReference: " << incrementWithReference() << std::endl;
   std::cout << "withCopy: " << incrementWithCopy() << std::endl;
}

两个函数的逻辑均是将uint32_t视为两个uint16_t分别递增：

• incrementWithReference通过std::for_each传引用原地修改input
• incrementWithCopy通过std::transform将修改后的值写入新变量output

核心原因：严格别名规则（Strict Aliasing Rule） #

编译器移除incrementWithReference的修改代码，根源是违反了C++标准的严格别名规则，触发了未定义行为（UB）：

• C++标准[basic.lval]条款规定：程序不能通过一个类型的指针/引用访问另一个不兼容类型的对象，唯一例外是可以通过char/signed char/unsigned char类型的指针访问任意对象。
• 这里uint32_t和uint16_t属于不兼容类型，你通过reinterpret_cast得到的uint16_t*去访问原本的uint32_t对象，无论是读取还是修改，都属于未定义行为。
• 编译器有权假设程序不会触发未定义行为，因此会认为input的值从未被修改，直接返回初始的0——这是完全符合标准的优化行为。

而incrementWithCopy看似也用了reinterpret_cast，但它是将修改后的值写入output的uint16_t视图，最终返回的output是作为uint32_t直接读取的（没有通过其他类型指针访问它的写入操作），因此未触发同样的UB，优化后行为正常。

关于std::for_each的误解澄清 #

你提到cppreference说std::for_each的传入函数签名等效于接受const&，这是对文档的误解：

• 文档的意思是，可调用对象的参数可以是const T&，但这只是允许的签名之一，并非强制要求。std::for_each的要求是可调用对象能接受迭代器指向类型的引用（包括非const引用），你的lambda[](uint16_t &n){ ++n; }完全符合要求。
• 问题的根源不在std::for_each本身，而是前面的reinterpret_cast违反严格别名规则导致的UB，和std::for_each的参数签名无关。

额外问题解释：取消注释后为何行为改变？ #

取消第10行的std::cout注释后，Clang 15 -O3下incrementWithReference返回预期值，原因是：

• 注释取消后，代码中出现了std::cout << *begin;，这同样是通过uint16_t*读取uint32_t对象，属于UB。
• 但编译器遇到IO操作（具有可见副作用）时，可能会调整优化策略，为了保证IO输出的"合理性"，保留了后续的修改代码。
• 注意：这仍然是未定义行为，不同编译器、不同版本可能有不同行为，绝对不能依赖这种方式来"修复"问题。

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