问题描述

在 gcc/common/config/aarch64/aarch64-common.cc 中，aarch64_handle_option() 会在处理 AArch64 选项时无条件调用 reset_tsv110_option()。该函数会读取宿主机 /proc/cpuinfo，并在检测到 vendor_id == 0x48 && part_id == 0xd01 时把默认的 aarch64_flag_outline_atomics 从 2 改成 0。

这意味着在 Kunpeng 宿主机上执行交叉编译时，即使目标 CPU 并不是当前宿主机型号，编译器默认代码生成行为也会被宿主机环境悄悄影响，最终导致同一份命令行在不同构建机上产生不同的默认 AArch64 代码路径。

根因分析

1. reset_tsv110_option() 的调用位置过早且过宽。当前它在 aarch64_handle_option() 中被无条件执行，而不是只在明确选中了相关目标 CPU 时执行。
2. 该逻辑依赖的是宿主机 /proc/cpuinfo，而不是用户通过 -mcpu / -march 指定的目标 CPU 信息，因此天然不适合交叉编译场景。
3. 一旦宿主机满足 vendor_id == 0x48 && part_id == 0xd01，就会把默认 outline-atomics 策略改写为 0，从而把“宿主机特征”错误带入“目标机代码生成策略”。

修复方向

建议把这段逻辑收敛到真正与目标 CPU 绑定的路径上，避免宿主机状态污染目标代码生成：

• 仅在明确选中相关 CPU/调优目标时再评估该逻辑，而不是对所有 AArch64 选项统一触发。
• 在交叉编译场景下避免直接读取宿主机 /proc/cpuinfo 决定目标机默认行为。
• 如果确实需要针对特定平台调整默认 outline-atomics，建议改为基于 -mcpu / -mtune 的目标信息做判断，或改成显式开关，而不是隐式宿主机探测。