OpenMP下GCC使用-O3与-march=native时求和异常问题咨询

结论 #

你遇到的问题是GCC 8.3版本的已知优化Bug，你的代码本身不存在数据竞争，也完全符合C与OpenMP规范。

原因分析 #

1. 代码同步逻辑合规
   你在ThreadCommunicator_allreduce_sum_l中的同步逻辑是合理的：每个线程先写入自身对应的omp_longval成员，之后调用#pragma omp barrier做全局同步。按照OpenMP规范，barrier会隐式执行全变量刷新（flush），所有线程对共享变量的写入都会对其他线程可见，后续所有线程读取其他线程omp_longval的操作完全合法，不存在数据竞争。

2. 编译器优化缺陷触发条件
   GCC 8.3.x在-O3优化等级下，针对AVX512架构做循环向量化优化时存在已知缺陷：编译器没有正确识别到omp_longval这类共享结构体成员会被其他线程修改，错误地将循环中读取self->parent->threads[rank]->omp_longval的操作优化为读取寄存器缓存的旧值，甚至直接用初始化的0值参与计算，最终导致sum计算结果异常。

为什么你的修改可以解决问题 #

• 把-O3替换为-O2：O2等级不会开启激进的循环向量化优化，不会触发这个编译器缺陷
• 移除-march=...参数：目标架构不指定为AVX512的情况下，编译器不会启用对应的向量化优化逻辑，自然不会踩坑
• 把self->parent->num_threads替换为omp_get_num_threads()：omp_get_num_threads()是外部函数调用，对编译器来说属于优化屏障，会强制编译器放弃寄存器中缓存的结构体成员值，每次循环都重新从内存读取，刚好绕开了优化错误
• 其他机器编译正常：要么是CPU不支持AVX512，要么是GCC版本不是8.3.x这个存在缺陷的版本

规避方案 #

1. 优先升级GCC版本到9.x及以上，这个Bug在后续版本已经被官方修复
2. 如果必须使用GCC 8.3，可以在ThreadCommunicator_allreduce_sum_l的sum计算循环前加一句#pragma omp flush手动强制刷新内存，或者给ThreadCommunicator_s结构体的omp_longval成员加volatile修饰，也能稳定规避这个问题

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