On Tue, 1 Apr 2025 at 16:02, Andrew Dunstan <and...@dunslane.net> wrote: > > > On 2025-04-01 Tu 5:16 AM, vignesh C wrote: > > On Sun, 2 Feb 2025 at 00:52, Lars Kanis <l...@greiz-reinsdorf.de> wrote: > >> This patch limits the workaround of using __buildin_setjmp on the > >> Windows MINGW platform. This workaround is only necessary for legacy > >> MSVCRT based toolchain, but not for UCRT based. It is not available at > >> all on clang on ARM64 resulting in the following compiler error: > >> > >> error: __builtin_longjmp is not supported for the current target > >> > >> This patch is used since years in MSYS2 packages: > >> > >> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-postgresql/postgresql-14.0-use-mingw-setjmp-on-ucrt.patch > >> > >> It is also used in ruby-pg to allow compiling for > >> aarch64-w64-windows-gnu: https://github.com/ged/ruby-pg/pull/626/files > >> > >> It would be nice if this patch could be merged upstream. > > Are there any known issues with using __builtin_setjmp? I'm asking > > because the comment mentions about the long standing issues in its > > setjmp "However, it seems that MinGW-64 has some longstanding issues > > in its setjmp support, so on that toolchain we cheat and use gcc's > > builtins. Also few users have reported segfaults when using setjmp > > with MinGW as in [1]. > > [1] - > > https://stackoverflow.com/questions/53709069/setjmp-longjmp-in-x86-64-w64-mingw32 > > > > That report is from quite a few years ago, so I'm not sure it really helps. > > If one of you would add this to the next CF we could see how the CFbot > reacts to it. In general it looks sane.
There is an existing CF entry for this at [1]. If no one picks this till the end of this CF, we can move it to next CF. [1] - https://commitfest.postgresql.org/patch/5610/ Regards, Vignesh
