I started wondering about $SUBJECT after noting that a very small number of places in our code have tests like
#if defined(__x86_64__) || defined(__x86_64) || defined(_M_X64) /* gcc, msvc */ That's from src/include/port/atomics/arch-x86.h, and the last two checks are demonstrably useless, because that whole file only gets included if #elif defined(__i386__) || defined(__i386) || defined(__x86_64__) #include "port/atomics/arch-x86.h" I did some googling and found https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-180 which says nothing about either __i386__ or __x86_64__, but does aver that _M_X64 Defined as the integer literal value 100 for compilations that target x64 processors or ARM64EC. Otherwise, undefined. So now I'm wondering if they predefine __i386__ or __x86_64__ and just don't feel a need to document that. If not, how the heck does our code build on MSVC? Are we missing a whole lot of CPU-specific optimizations there? Also, after reading up on what ARM64EC means: https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/ it seems like Microsoft has managed to break _M_X64 pretty thoroughly, because now that symbol doesn't necessarily mean that you're on Intel hardware. So I'm thinking we need to transition away from depending on it to make architecture choices. Not that we were doing so in very many places, but it seems outright dangerous to use now: people might cargo-cult use of that symbol into places where it's not already certain that we're building for Intel. Not being a Windows person, I can't easily answer these questions by experiment. But I think they need answering (and then documenting). regards, tom lane
