`std.Target`: A bunch of C type size/alignment fixes by alexrp · Pull Request #20960 · ziglang/zig

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp · 2024-08-06T18:38:34Z

Fixes a bunch of issues uncovered with the help of #20951.

There are still some remaining issues for avr, but I am not making any changes there until there's a resolution to [clang][AVR] Alignment discrepancies between clang and avr-gcc for short, long long, and double llvm/llvm-project#102172.
It's worth noting that the default ABI choices that Clang makes for m68k-linux-gnu are different from the ones that GCC does; in particular, Clang defaults to -malign-int while GCC does not. We'll stick with the Clang default for now, but this makes us incompatible with at least the Debian m68k port, which is fairly problematic since AFAIK that's the only active m68k Linux distro. (Obligatory plug for RFC/Proposal: Turning Zig target triples into quadruples #20690.)
While working on this, it became clear that the spir/spir64 removal in std.Target: Remove more dead OS/architecture tags #20870 was too hasty. These tags are actually still used in target triples like spir-unknown-unknown which means to target the OpenCL SPIR environment and emit SPIR-V bytecode (no, not SPIR bytecode). This of course means that they really represent an environment/ABI now, not real "architectures". So the sensible thing to do is to reintroduce spir as an Abi tag that can be used as spirv[32,64]-opencl-spir. I'll do this in a follow-up PR.

The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

This value was correct for the old SPIR, but not for SPIR-V.

… not 16).

…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

alexrp · 2024-08-06T18:41:26Z

cc @Snektron for the GPU bits, @koachan for the sparc bits.

alexrp · 2024-08-06T20:15:35Z

By the way, the methodology here was just:

zig run generate_c_size_and_align_checks.zig -- <zig triple> | clang --target=<clang triple> -fsyntax-only -xc -

Follow-up on `std.Target` GPU changes in #20960

alexrp added 14 commits August 6, 2024 20:17

std.Target: Fix ptrBitWidth_cpu_abi() for dxil (64-bit, not 32-bit).
ab154be
The DXIL documentation claims 32-bit pointers: https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#memory-accesses Despite this, Clang considers pointers 64-bit when targeting it.

std.Target: Fix ptrBitWidth_cpu_abi() for sparc32.
db8f00e
CPU feature set has nothing to do with ABI choice; the pointer bit width is determined only by looking at the choice of sparc vs sparc64.

std.Target: Fix C type alignment calculation for dxil.
e67388c

std.Target: Fix C type alignment calculation for spirv32.
29321ca

std.Target: Fix C type alignment calculation for loongarch64.
98153c8

std.Target: Fix C type alignment calculation for sparc64.
e678862

std.Target: Fix C type alignment calculation for ve.
5dd66cd

std.Target: Fix C long long size for opencl (8, not 16).
606d011
This value was correct for the old SPIR, but not for SPIR-V.

std.Target: Fix C long double size for opencl (8, not 16).
a1d3e56
This value was correct for the old SPIR, but not for SPIR-V.

std.Target: Fix C long double size for amdhsa, amdpal, and mesa3d (8,…
eef4998
… not 16).

std.Target: Fix C long double size for sparc32 (8, not 16).
7b47ebe

std.Target: Fix C long double size for ve (16, not 8).
231f322

std.Target: Treat spirv as identical to spirv64 for ABI size/alignmen…
23b5a6c
…t purposes. This is arbitrary since spirv (as opposed to spirv32/spirv64) refers to the version with logical memory layout, i.e. no 'real' pointers. This change at least matches what clang does.

std.Target: Handle mesa3d in c_type_bit_size().
ef502da

Snektron reviewed Aug 6, 2024
View reviewed changes

Comment threadlib/std/Target.zig

Snektron approved these changes Aug 6, 2024
View reviewed changes

andrewrk merged commit c8a226a into ziglang:masterAug 6, 2024

alexrp deleted the size-align-fixes branch August 6, 2024 23:08

This was referenced Aug 8, 2024
Follow-up on std.Target GPU changes in #20960 #20985
Merged
Record layout tests failing for sparc-v9-solaris-eabi:ClangVexu/arocc#747
Closed

andrewrk added a commit that referenced this pull request Aug 12, 2024
Merge pull request#20985from alexrp/gpu-nonsense
61dac74
Follow-up on `std.Target` GPU changes in #20960