在 2026-6-6 22:58, Pali Rohár 写道:
I have addressed all issues except the first one. New changes rebased on the current master branch are in the attachment. Just I do not know what to do with the first change. I dropped sigsetjmp/siglongjmp and fegetenv/fegetexceptflag changes. sigsetjmp/siglongjmp is only in the test and fegetenv/fegetexceptflag were already merged.Also in the second attachment t_sigfpe_msvc.patch I'm sending change which allows to compile t_sigfpe.c test with msvc/ucrt and therefore validate that the behavior of SIGFPE is same (correct). I'm not sure if this change is useful for mingw-w64 project, so I'm sending it separately (I used it for debugging and verification).
Probably not.
From 67a542e146a7dfbd522b1fb68f261dbd50d97ec0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pali=20Roh=C3=A1r?=<[email protected]> Date: Tue, 23 Dec 2025 01:50:47 +0100 Subject: [PATCH 01/27] headers: Fix PEXCEPTION_ROUTINE type definition PEXCEPTION_ROUTINE is a SEH handler function in which callee does not pop passed arguments, so it should have __cdecl keyword. In MS DDK up to (and including) the DDK 3790.1830 (Windows Server 2003 with Service Pack 1 DDK), this PEXCEPTION_ROUTINE type definition in ntdef.h was without an explicit calling convention, which is by default __cdecl (unless via compile flags not changed). Starting from WDK 6000 (Windows Driver Kit for Windows Vista) there is NTAPI marker (which is __stdcall calling convention). MS probably added it here because no one was defined and most NT functions are using __stdcall. This is fine for AMD64 where both __stdcall and __cdecl are aliases, but it is incorrect for I386. In all I386 CRT libraries are all known I386 SEH handlers (_except_handler2, _except_handler3, _except_handler4_common) of PEXCEPTION_ROUTINE type using __cdecl calling convention. This can be simple verified by gendef or examining output of objdump. So fix the incorrect calling convention marker for PEXCEPTION_ROUTINE in ntdef.h and winnt.h files. This fixes compile warnings generated by gcc that calling convention mismatch when trying to assign SEH handler function into the EXCEPTION_REGISTRATION_RECORD.Handler structure member.
I'm not convinced about this change. As a matter of fact, this is not the only thing that lacks an explicit calling convention; the functions `SystemFunction0{36,40,41}` were also declared without calling conventions, until Windows 10 SDK.
What does this mean? This means that when building their system DLLs, Microsoft have a default calling convention of `__stdcall` (`/Gz` for MSVC, `-mrtd` for GCC and Clang); it has always been the case on x86-32. This also explains why standard C functions in Microsoft CRT have explicit `__cdecl`, otehrwise they would have the wrong calling convention.
Not having a calling convention on `EXCEPTION_ROUTINE` was a bug which they have fixed, and they say it is `__stdcall`.
--- /dev/null
+++ b/mingw-w64-crt/testcases/t_sigfpe.c
+static void clear_x87_stack(void)
+{
+ /* On x86, every cdecl function must clear the x87 stack, callers expect it.
Not true if the function returns `float`, `double` or `long double`; but this is in test code, so despite the inaccuracy of information, I'm not gonna fix this.
The other changes look good. -- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
