[build@build /usr/home/build]$ cat hello.c
int main(int argc, char **argv) {
return 0;
}
[build@build /usr/home/build]$ clang -c hello.c -march=native
error: unknown target CPU 'athlon-xp'
note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont,
goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i,
haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cannonlake,
icelake-client, icelake-server, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3,
athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4,
znver1, x86-64
This is happening because the environment has the CPU name incorrect. It is reporting athlon-xp
which is a 32-bit CPU, however the system is 64-bit.
This is causing many tests from Zig's test suite to fail, because it passes -march=native
for the native target when importing .h files and compiling C code.
We had issues for a long time with FreeBSD failing to boot up on an EPYC host. The workaround was to tell qemu to override the CPU host model to the most conservative value. However, we set
-cpu qemu64
- which is a 64-bit CPU model. It seems like something more subtle is wrong if you're detecting a 32-bit CPU somewhere. Have you raised the problem with Clang? How does it determine that "athlon-xp" is the CPU family?
It's a QEMU bug
FWIW, even though qemu64 is the default CPU, practically everyone would be better off choosing one of the other CPU models explicitly to better suit their desired use case. There is some guidance here https://qemu.weilnetz.de/doc/qemu-doc.html#cpu_005fmodels
Through some testing, it looks like FreeBSD boots up with
-cpu host
now, so the workaround is no longer necessary. I'll get the change deployed. Cheers!
That's great news. Thank you