C++ Armadillo矩阵构建异常：两种累加写法导致收敛差异

• 两段代码的唯一语义差异是浮点数累加的组织形式：一段是将所有修正项累加到临时变量sum，最终一次性写入f_mo(p,q)；另一段是每轮循环直接对f_mo(p,q)做就地累加
• 完成f_mo计算后，直接对比两种写法输出的f_mo矩阵，在机器精度范围内完全一致
• 基于表象推断，两种写法传入后续流程的输入应完全等价，但实际while循环的收敛速度、最终收敛能量、总迭代次数存在巨大差异
• 已排除常规干扰项：多次重复运行结果稳定、关闭全量编译优化后问题复现、同环境跨机器复现问题、差异首次出现的固定锚点为后续循环中重算的g_mat_full_qp1_qp2_mo变量
• 已确认两种写法下，所有输入到g_mat_full_qp1_qp2_mo计算流程的表面可见变量取值完全一致

• Armadillo矩阵视图的内存别名（最高发诱因）
  Armadillo的子矩阵、切片操作返回的是不持有独立内存的视图，直接指向原矩阵的内存位置。如果此前代码存在类似arma::mat g_mat = f_mo.submat(...)的操作而没有做深拷贝，就会出现内存重叠：
  当直接对f_mo做就地累加时，每一次写f_mo的操作都会直接修改被视图绑定的g矩阵内存，而循环内后续读g矩阵元素的操作，就会拿到被中途修改的值；使用临时sum累加的写法，所有g矩阵的读操作都发生在最后一次写f_mo之前，刚好避开了这个读写冲突。最终打印的f_mo数值没有明显差异，但中间过程读到的g矩阵值已经发生偏移。
• x87扩展精度带来的中间计算差异
  浮点数的80位x87扩展精度是编译时指定的指令集特性，和优化等级无关。即使在O0下，只要编译器默认使用x87指令集，中间计算的浮点数会暂时存在80位宽度的寄存器中：
  直接就地累加的写法每一步都会把计算结果写入f_mo的内存，触发从80位到64位double的截断；临时sum的写法会把累加值一直存在80位寄存器中，直到最后才写入内存。哪怕最终落盘的f_mo二进制值完全一致，这种中间截断的微小差异（通常小于1e-16）会在自洽迭代的过程中被逐步放大，最终体现为收敛路径的巨大差异。
• 越界访问导致的未定义行为
  代码中所有g矩阵的取值都使用手工计算的线性索引（如p*n_mo + q、i2*n_mo2 + i2），如果存在尺寸不匹配、索引计算偏移的问题，就会触发越界内存访问：
  临时sum写法和直接就地累加写法的内存写顺序不同，越界写入的位置也会存在细微差异，通常不会触发程序崩溃，只会悄无声息修改到后续计算需要用到的g_mat_full_qp1_qp2_mo的内存块，且跨机器运行时因为内存布局相对固定，问题可以稳定复现。

• 对两种写法生成的f_mo矩阵做二进制级别的逐元素对比（使用memcmp直接对比内存块，而非仅对比浮点数值差），确认是否真的不存在精度差异
• 拿到所有关联矩阵的首地址与内存范围，检查是否存在内存地址重叠：依次对比f_mo、h_core_mo、所有g_mat_*矩阵的内存区间，确认是否存在未做深拷贝的视图绑定
• 编译时强制关闭x87扩展精度，添加编译选项-ffloat-store -msse2 -mfpmath=sse，强制所有浮点中间计算使用64位SSE指令，验证问题是否消失
• 在f_mo计算完成后、开始计算g_mat_full_qp1_qp2_mo之前，对f_mo的内存块设置只读保护，若后续流程出现写权限错误，即可确认存在视图绑定的内存别名问题
• 逐元素对比两种写法下g_mat_full_qp1_qp2_mo的计算结果，定位第一次出现非零差值的位置，回溯该位置的输入取值差异

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