的X32 ABI指定，除其他事项外，对于x86_64体系生成的代码32位指针。它结合了 x86_64 架构（包括 64 位 CPU 寄存器）的优点和 32 位指针减少的开销。
的<stdint.h>报头定义的typedef int_fast8_t，int_fast16_t，int_fast32_t，和int_fast64_t（和相应的无符号类型uint_fast8_t等人）中，其中的每一个是：
在所有至少具有指定宽度的整数类型中，通常操作最快的整数类型
附注：
不能保证指定的类型在所有用途中都是最快的；如果实现没有明确的理由选择一种类型而不是另一种，它只会选择一些满足符号和宽度要求的整数类型。
（引自N1570 C11 草案。）
问题是，无论有没有 x32 ABI ，应该如何为 x86_64 架构定义[u]int_fast16_t和[u]int_fast32_t类型？是否有指定这些类型的 x32 文档？它们是否应该与 32 位 x86 定义（均为 32 位）兼容，或者，由于 x32 可以访问 64 位 CPU 寄存器，它们在使用或不使用 x32 ABI 的情况下是否应该具有相同的大小？（请注意，无论是否使用 x32 ABI，x86_64 都有 64 位寄存器。）
这是一个测试程序（取决于特定于 gcc 的__x86_64__宏）：
#include <stdio.h>
#include <stdint.h>
#include <limits.h>
int main(void) {
#if …X32是使用 32 位指针的amd64/ CPU的 ABI 。x86_64这个想法是将 x86_64 的较大寄存器集与 32 位指针产生的较小内存和缓存占用空间结合起来。它可提供高达约 40% 的加速。有关详细信息以及将其设置为 chroot 环境，请参阅Stack Overflow 上的x86、x32 和 x64 架构之间的差异以及 Debian X32 Ports wiki 页面。
我们收到了 Debian 维护者在该环境下的错误报告。该报告adcq是非法指令。内联汇编是根据预处理器宏激活的，因此我们没有正确检测到 X32（或者更正确地说，到目前为止根本没有检测到）。
对于预处理器宏来说，最明显的选择（对我来说）是类似的__X32__，但没有提供。根据Clang的补丁和Debian的建议，看起来__ILP32__可以使用。但我想要一个更规范的答案，_ILP32而且__code_model_small__看起来也很有趣。（我知道 SSE2 存在问题，编译器支持它，但操作系统不支持）。
使用 Clang 和 GCC 时，可以使用哪些预处理器宏来可靠地检测 X32 ABI 和环境？
需要明确的是，我此时并不想修复代码。我只是想知道可以用于完整修复的宏。
# cpp -dM < /dev/null | sort
#define __amd64 1
#define __amd64__ 1
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_ACQUIRE 2 …