On Tue, Jul 28, 2026, at 11:35 AM, Nathan Bossart wrote:
> On Tue, Jul 28, 2026 at 09:10:54AM -0400, Greg Burd wrote:
>> * clang for aarch64-w64-windows-gnu does not implement
>> __builtin_setjmp at all; and
>
> Does clang for x86-64 implement it?
Yes. I checked clang 22.1.8 across a range of targets by compiling
int test(void) {
void *buf[5];
if (__builtin_setjmp(buf)) return 1;
__builtin_longjmp(buf, 1);
return 0;
}
target __builtin_setjmp
------------------------- ----------------
x86_64-pc-linux-gnu compiles
x86_64-w64-windows-gnu compiles
aarch64-linux-gnu error: not supported for the current target
aarch64-w64-windows-gnu error: not supported for the current target
aarch64-pc-windows-msvc error: not supported for the current target
arm64-apple-darwin error: not supported for the current target
So it is not MinGW- or Windows-specific: clang implements
__builtin_setjmp/__builtin_longjmp for x86-64 but rejects it on *every*
aarch64 target I tried, including aarch64-linux and arm64-darwin, with
the same "not supported for the current target" diagnostic. In LLVM
these builtins lower to the EH_SjLj intrinsics, which have target
support on x86 but not on AArch64; it's an architecture-level gap in the
backend, not a property of the MinGW runtime.
That is actually reassuring for the patch's scope: the reason we only
hit this on aarch64 MinGW (and not, say, aarch64 Linux) is simply that
the c.h block that reaches for the builtins is guarded by WIN32 &&
__MINGW64__. On aarch64 Linux we never take the builtin path in the
first place; on aarch64 MinGW we do, and it doesn't compile. Restricting
that path to !defined(__aarch64__) lines aarch64 MinGW up with the plain
setjmp()/longjmp() that every other non-x86_64-MinGW toolchain already
uses.
> Testing on aarch64/gcc/mingw seems like an important step.
Agreed, and I want to be upfront that I have not been able to test that
combination yet -- I don't currently have an aarch64 GCC MinGW toolchain
(the llvm-mingw / MSYS2 clangarm64 toolchain I build with is clang-based,
which is where the aarch64 buildfarm work has been happening). So the
runtime evidence I offered ("25/25 elog(ERROR)->siglongjmp cycles, nested
PL/pgSQL exceptions, no crash") is specifically for clang-aarch64-mingw,
whose setjmp lowering is its own thing. I should not have implied
anything broader.
The relevant question your ask raises is: on aarch64 GCC MinGW, does GCC
even implement __builtin_setjmp (so the current code would compile there),
and if so, does the original MinGW-64 setjmp defect from 146cb3889c3
manifest on aarch64 the way it does on x86_64? I can't answer that
without the toolchain. There seem to be two reasonable paths:
1. Keep the patch conservative as written: it only changes
aarch64 MinGW, where clang can't compile the builtin at all, and it
matches what non-MinGW Windows already does. If a GCC aarch64
MinGW build later turns out to need the builtins (i.e. GCC does
implement them there AND the plain-setjmp defect recurs on
aarch64), that would be a follow-up refinement of the condition
(e.g. gate on the compiler as well as the arch), not a reason to
hold this.
2. Hold until someone can stand up aarch64 GCC MinGW and confirm. I'm
wary of this because clang-aarch64-mingw is broken today with no
workaround, and I'm not sure anyone is actively running a GCC
aarch64 MinGW build of Postgres.
I'd lean toward (1) but I'm happy to be guided. If it helps, I can also
narrow the guard to be explicit about the mechanism, e.g. only take the
__builtin_setjmp path when the compiler actually provides it, rather than
keying off arch -- though on x86_64 GCC/clang MinGW that's a
distinction without a difference today. If anyone has an aarch64 GCC
MinGW environment handy, I'd gladly take help confirming both the
compile and the setjmp/longjmp runtime behavior there.
> --
> nathan
best.
-greg
