On 23.04.2025 18:50, Martin Storsjö wrote:
On Wed, 23 Apr 2025, Martin Storsjö wrote:

On Wed, 23 Apr 2025, Jacek Caban wrote:

Instead of for specific architectures. Fixes setjmp on ARM64EC.
---
v2: Reorder checks to simplify the code a bit. We could probably simplify it further
by removing defined(__SEH__) checks.

mingw-w64-headers/crt/setjmp.h | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/mingw-w64-headers/crt/setjmp.h b/mingw-w64-headers/crt/setjmp.h
index 2dc7d8739..8bfab5c58 100644
--- a/mingw-w64-headers/crt/setjmp.h
+++ b/mingw-w64-headers/crt/setjmp.h
@@ -229,16 +229,14 @@ void * __cdecl __attribute__ ((__nothrow__)) mingw_getsp (void);
#    define longjmp __mingw_longjmp
  int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) __mingw_setjmp(jmp_buf _Buf);   __MINGW_ATTRIB_NORETURN __attribute__ ((__nothrow__)) void __mingw_longjmp(jmp_buf _Buf,int _Value);
-#  elif defined(__SEH__) && !defined(__USE_MINGW_SETJMP_NON_SEH)
-#    if defined(__aarch64__) || defined(_ARM64_) || defined(__arm__) || defined(_ARM_)
-#      define setjmp(BUF) _setjmp((BUF), __builtin_sponentry())
-#    elif (__MINGW_GCC_VERSION < 40702) && !defined(__clang__)
-#      define setjmp(BUF) _setjmp((BUF), mingw_getsp())
-#    else
-#      define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
-#    endif
-#  else
+#  elif !defined(__SEH__) || defined(__USE_MINGW_SETJMP_NON_SEH)
#    define setjmp(BUF) _setjmp((BUF), NULL)
+#  elif __has_builtin(__builtin_sponentry)
+#    define setjmp(BUF) _setjmp((BUF), __builtin_sponentry())
+#  elif (__MINGW_GCC_VERSION < 40702) && !defined(__clang__)
+#    define setjmp(BUF) _setjmp((BUF), mingw_getsp())
+#  else
+#    define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))

Sorry, I think I was unclear; the condition which I find most unwieldy is the one above this block entirely. These ones aren't all that bad. The one I found problematic was this one:

#  elif ((defined(_ARM_) || defined(__arm__) || defined(_ARM64_) || defined(__aarch64__)) && (!defined(__SEH__) || !__has_builtin(__builtin_sponentry) || defined(__USE_MINGW_SETJMP_NON_SEH)))

The annoying thing here is that it repeats many of the conditions that we have below...

It would at least be less annoying if we'd get rid of the duplicate _ARM_ vs __arm__ checks everywhere. But even then, I'm not sure how much we can simplify it? As we do need to decide if we want to use the SEH-requiring _setjmp or __mingw_setjmp.

As far as I see it, we have these cases we've considered:

- x86_64, with __SEH__ defined, with mingw_getsp() or __builtin_frame_address(), with GCC or Clang - Old aarch64 clang, with __SEH__ defined but without __builtin_sponentry(). We probably don't need to support this any longer - this was for Clang before version 9. - Old armv7 clang, without __SEH__ defined. (This was Clang before version 15.) Not very important, but I think we added __SEH__ in sync with adding __builtin_sponentry() there, so I think this case may be handled essentially for free. - New aarch64 and armv7 clang, with __SEH__ defined, with __builtin_sponentry() available - Aarch64 and armv7 clang, with __SEH__ defined, but the user defined __USE_MINGW_SETJMP_NON_SEH - Aarch64 GCC, probably without __SEH__ defined, with no __builtin_sponentry()

I forgot a couple other cases:
- Aarch64 and armv7 clang, but with -fdwarf-execptions; this makes __SEH__ no longer be predefined. Not a very important case, but I think we do need to check for __SEH__ to cover many of the odd configurations anyway.


Yes, I assumed you were referring to that part, but I didn’t immediately see a way to simplify it. Even if we drop support for older Clang versions, the GCC case still requires the target macro checks. That said, your point about __SEH__ and __builtin_sponentry() does help reduce some duplication, so I’ll send an updated version.


Thanks,

Jacek



_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to