底层架构最近在我的云服务器上发生了变化，看起来很像
使用gcc -march=native编译的代码遇到问题（Ubuntu 14.04，gcc 4.8）
它曾经一直运行在16核Intel Xeon E5-2650 v2上，现在不时（取决于我猜测的可用性）它会得到更快的Xeon E5-2650 v3。
二进制工作，但现在看起来在无锁线程同步代码中存在奇怪的未定义行为，而之前它曾经100％工作。我唯一能想到的是代码以某种方式编译为v3并在v2上运行（或者反过来）并且两者之间存在一些不兼容性。
我宁愿在将来避免这种情况。有没有一种很好的方法来检测为错误的架构编译的二进制文件？
编辑：我查了一下，gcc文档非常清楚-march=native：
-march = CPU型
生成机器类型cpu-type的指令。在对比-mtune = CPU型，这仅仅调谐为指定的CPU型生成的代码，-march = CPU型允许GCC生成可能无法在一个比指示的其他处理器中的运行代码。指定-march = cpu-type意味着-mtune = cpu-type。“天然”
这将通过确定编译器的处理器类型来选择CPU以在编译时生成代码。使用-march = native可以启用本地计算机支持的所有指令子集（因此结果可能无法在不同的计算机上运行）。
v2和v3之间的区别看起来相当可观，标志gcc -march=native使用引擎盖（strings prg | grep march，如果prg是用调试符号编译的）。 v3添加了所有这些并更改了l2-cache-size：
-mabm -mavx2 -mbmi -mbmi2 -mfma -mlzcnt -mmovbe
如果使用这些新指令集中的任何一个，就像为MMX编译一些东西并期望它在非MMX拱门上运行...
答案 0 :(得分：0)
GCC将为其使用的架构定义预定义的宏 - 例如-march=core2将定义宏__core2。您可以在程序中包含一个命令行选项，该选项使用这些宏来显示其编译的体系结构 - 在这种情况下，您要检查__ivybridge和__haswell。
或者（或者也可以），您可以让程序显示用于编译它的编译器标志（通过让您的构建系统为程序提供这些标志）。但是，如果您使用-march=native，那将无济于事。
听起来你的问题更可能是程序中的潜在错误，特别是因为它涉及线程同步 - 较新的机器可能会更积极地重新排序内存访问，这会在无锁算法中暴露出一个缺失的障碍。 / p>