unknown target CPU 'athlon-xp'

[Ivan-Velickovic]

Zig Version

0.14.0-dev.2178+bd7dda0c5

Steps to Reproduce and Observed Behavior

Run the following command: zig cc anything.c

no need to create anything.c.

Get the following output:

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, cooperlake, cannonlake, icelake-client, rocketlake, icelake-server, tigerlake, sapphirerapids, alderlake, raptorlake, meteorlake, arrowlake, arrowlake-s, lunarlake, gracemont, pantherlake, sierraforest, grandridge, graniterapids, graniterapids-d, emeraldrapids, clearwaterforest, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, znver3, znver4, znver5, x86-64, x86-64-v2, x86-64-v3, x86-64-v4

This occurs on Linux x86_64, my uname -a looks like this: Linux vista-genetic 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

my /proc/cpuinfo looks like this:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 94
model name      : Common KVM Processor v5
stepping        : 3
microcode       : 0x1
cpu MHz         : 2593.904
cache size      : 16384 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt xsavec xgetbv1 arat md_clear
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds mmio_stale_data retbleed
bogomips        : 5187.80
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Let me know if I need to give any more information about the system. The only other perhaps notable context is that it is a virtual machine.

Expected Behavior

No error message.

[rohlem]

Not familiar with issues like this, but did you build Zig yourself, or download a master/nightly build? (I assume building with a system-provided LLVM/Clang that was patched somehow could lead to issues like this?) EDIT: I think the "native" section from the end of the output of zig targets might also be of interest, but not sure.

[patryk4815]

@Ivan-Velickovic probably you use -cpu max in qemu-system (I had same issue)? Different cpu should workaround your issue eg: -cpu EPYC-v4

[rohlem]

(Note that even if there's a workaround, I think we'd still be interested in fixing this, so please keep the issue open. Zig should ideally work on all CPUs.)

[andrewrk]

athlon_xp appears to be a 32-bit CPU only. The error comes from clang because zig detects the CPU as athlon_xp and therefore sends athlon-xp to clang, but clang rejects it because the target is x86_64.

Therefore, this is a bug in the CPU detection, it seems that the host CPU is not in fact athlon_xp.

https://github.com/ziglang/zig/blob/54d0ba418375a4665cf1b4ee876d6c750bb9c079/lib/std/zig/system/x86.zig#L237-L240

perhaps the bug is here

[Ivan-Velickovic]

@Ivan-Velickovic probably you use -cpu max in qemu-system (I had same issue)? Different cpu should workaround your issue eg: -cpu EPYC-v4

This is in a VPS that I rent so I unfortunately can't control how it's being virtualised.

[Ivan-Velickovic]

Not familiar with issues like this, but did you build Zig yourself, or download a master/nightly build?

Downloaded from the Zig website.

[chrboesch]

@Ivan-Velickovic Could you please run the following code and let me know the result?

const std = @import("std");

const CpuidLeaf = struct {
    eax: u32,
    ebx: u32,
    ecx: u32,
    edx: u32,
};

fn cpuid(leaf_id: u32, subid: u32) CpuidLeaf {
    var eax: u32 = undefined;
    var ebx: u32 = undefined;
    var ecx: u32 = undefined;
    var edx: u32 = undefined;

    asm volatile ("cpuid"
        : [_eax] "={eax}" (eax),
          [_ebx] "={ebx}" (ebx),
          [_ecx] "={ecx}" (ecx),
          [_edx] "={edx}" (edx),
        : [_in_eax] "{eax}" (leaf_id),
          [_in_ecx] "{ecx}" (subid),
    );

    return .{ .eax = eax, .ebx = ebx, .ecx = ecx, .edx = edx };
}

pub fn main() void {
    const leaf = cpuid(0, 0);
    std.debug.print("{s}{s}{s}\n", .{ std.mem.toBytes(leaf.ebx), std.mem.toBytes(leaf.edx), std.mem.toBytes(leaf.ecx) });
}

Because, target "athlon" is only in the AMD branch, but you have an Intel CPU. That's strange.

[Ivan-Velickovic]

The result is AuthenticAMD.

[chrboesch]

I suspected it, but I have no idea why your system shows "Intel" in /proc/cpuinfo, but outputs "AMD" via the register query. I suspect that this may have something to do with the virtual environment. Maybe you should take another look at the settings. What kind of CPU did you rent?

[chrboesch]

Now I've googled a bit and found out the following: Often the KVM settings are set in such a way that the CPU type is 'AMD', even though another hardware is providing the virtual environment. This then leads to the behavior you're observing. You can fix this by passing through the original CPU values ​​(called CPU Passthrough). This can be done using a setting in the KVM XML setup: <cpu mode="host-passthrough"/>

[Ivan-Velickovic]

I see.

What kind of CPU did you rent?

There wasn't any choice in the kind of CPU I can rent, it's just a vCPU hosted by https://www.binarylane.com.au/.

Often the KVM settings are set in such a way that the CPU type is 'AMD', even though another hardware is providing the virtual environment

I see. So I guess it's just an issue with the virtualisation of the CPU? Why does this only occur on Zig and not on Clang? Is it because Clang isn't trying to find the exact kind of x86 CPU by default?

[chrboesch]

I've been wondering that too, since /proc/cpuinfo also shows Intel. But I don't have a really good idea yet.

[chrboesch]

I've now looked at how LLVM does this and it's a lot more than what happens in Zig. Of course you can replicate this and you probably should, but that requires a lot more effort and, above all, testing. So I don't think there is a quick solution. Unfortunately.

Link to LLVM: https://github.com/llvm/llvm-project/blob/99fd1c5536547ed4fc360b16e7fa2e06278707a8/llvm/lib/TargetParser/Host.cpp#L1342