freebsd clang cannot build "hello world" C application with -march=native because the CPU id is incorrect

[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.

Assigned to
7 months ago
7 months ago
No labels applied.

~andrewrk 7 months ago

~sircmpwn 7 months ago

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?

~andrewrk 7 months ago

It's a QEMU bug

~andrewrk 7 months ago

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

~sircmpwn REPORTED FIXED 7 months ago

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!

~andrewrk 7 months ago

That's great news. Thank you

Register here or Log in to comment, or comment via email.