对齐数组中间存储数据：_mm256_store_si256为何未触发对齐错误？

这个问题得从x86 CPU的指令特性、操作系统对齐检查设置，还有编译器行为三个层面来解释，咱们一步步理清楚：

首先先明确你的代码里的地址对齐状态：

• 你用alignas(32)修饰了数组a，所以它的起始地址是严格32字节对齐的。
• int32_t是4字节类型，a+4相当于从数组起始位置偏移了4*4=16字节，所以a+4的地址是16字节对齐，但绝对不是32字节对齐——而_mm256_store_si256对应的AVX指令vmovdqa，理论上要求目标地址必须是32字节对齐的。

那为啥没触发错误？核心原因有两个：

1. 现代x86 CPU的容错机制 #

从Intel Sandy Bridge、AMD Bulldozer之后的CPU，都支持“不对齐AVX指令的软容错”：只要操作系统没开启对齐检查（CR0.AM位），不对齐的vmovdqa不会触发#AC（对齐检查异常），CPU会自动处理这个不对齐的内存访问，只是会有明显的性能损失（因为要拆分内存操作）。

而在几乎所有桌面/服务器操作系统的用户态环境里，CR0.AM位都是默认关闭的——这意味着用户态程序里的不对齐AVX操作不会崩溃，只是跑得慢一点。

2. 编译器的默认行为 #

像GCC、Clang这类主流编译器，默认情况下不会为_mm256_store_si256添加强制对齐检查的逻辑。只有当你开启了严格的编译选项（比如-mno-alignavx，或者某些调试模式），编译器才会帮你检测对齐问题，甚至插入报错逻辑。

另外要注意：_mm256_store_si256是要求对齐的指令，而_mm256_storeu_si256（带u后缀，代表unaligned）是明确允许不对齐访问的。你用前者访问不对齐地址，其实属于C++标准里的未定义行为——只是CPU和编译器帮你掩盖了问题，在旧CPU、内核态环境，或者开启对齐检查的场景下，这种操作大概率会直接崩溃。

验证地址对齐的小测试 #

如果你想确认a+4的对齐状态，可以加一段代码验证：

cout << "a的起始地址: " << reinterpret_cast<void*>(a) << endl;
cout << "a+4的地址: " << reinterpret_cast<void*>(a+4) << endl;
cout << "a+4是否32字节对齐: " 
     << (reinterpret_cast<uintptr_t>(a+4) % 32 == 0 ? "是" : "否") 
     << endl;

运行后你会发现a+4确实不是32字节对齐，但因为前面说的容错机制，所以没触发错误。

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