On my system (FROM registry.access.redhat.com/ubi9/ubi container), this happens when I try to build cffi extensions (for CPython).

In /bin/python3.9-x86_64-config, there is the following line

OPT="-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG  -O2  -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong   -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv"

Then, when I run cffi, it will pass these cflags to the compiler, and zig cc does not handle the -mtune=generic part.

 % echo "int main(void){return 1;}" | zig cc -target native-native -mtune=generic -x c -
error: unknown target CPU 'generic'
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, sierraforest, grandridge, graniterapids, emeraldrapids, 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, x86-64, x86-64-v2, x86-64-v3, x86-64-v4

zig cc -target native-native-gnu -mtune=generic /dev/null
[1]    56688 segmentation fault (core dumped)  zig cc -target native-native-gnu -mtune=generic /dev/null

Looked into this a bit on the LLVM and GCC sides. s390x is a bit of an outlier in that it doesn't have a generic value; neither GCC nor LLVM accept it. This is a bit confusing at first because LLVM's SystemZProcessors.td claims otherwise, yet Clang explicitly does not accept it here (which is used here).

The fix here probably has to be on the Zig side; the fact that both GCC and Clang reject generic strongly indicates that this is by design. It's also not clear what generic could be defined as that GCC and Clang could agree on since arch8 is the oldest version supported by LLVM, while GCC has support all the way back to arch5 (which is the default if -march is not given).

I believe that the right fix on the Zig side is to change std.Target.Model.baseline() to return arch8 for s390x. For context, arch5 is from 2000 while arch8 is 2008. I don't think there's any compelling reason to default to anything older than arch8 considering that IBM didn't even think that supporting pre-arch8 was necessary when they revived the LLVM backend in 2013.