On Sat, 29 Oct 2022, Martin Storsjö wrote:
On Fri, 28 Oct 2022, LIU Hao wrote:
This makes GDB build again in MSYS2.
I included this patch in my nightly build round, and it breaks compilation
for i686 with clang for some reason (failing a compiler internal consistency
check). I'll try to dig into it later...
It turns out that this was a rather obscure bug in Clang, that happens
under these conditions:
- We have a standard function which Clang knows about
- which is redirected to a different symbol name with __asm__
- which is given an inline implementation
- on a platform which uses symbol prefixes (i386 windows, or macOS)
https://reviews.llvm.org/D137073 should fix it (but it isn't merged yet).
Anyway, as for fixing the issue, we already have the situation where
__MINGW_FORTIFY_VA_ARG is defined to 0 on Clang (since it doesn't
implement __builtin_va_arg_pack()). The other instances that you're
changing in this patch, outside of the __MINGW_FORTIFY_VA_ARG blocks,
shouldn't be strictly necessary to change to fix the issue at hand -
they're just changed for consistency?
So either we'd keep those as-is and just patch the cases within
__MINGW_FORTIFY_VA_ARG, or we can add extra conditionals and two
implementation alterantives of these functions too - e.g. something like
this:
/* Clang < 16 has got problems with overriding builtin functions, that have
been renamed with __asm__, with a separate inline function, on targets
that use symbol prefixes (i.e. i386 for mingw targets). Avoid using such
codepaths for those targets. */
#if !defined(__i386__) || (defined(__GNUC___) && !defined(__clang__)) \
|| __MINGW_CLANG_PREREQ(16, 0)
# define __MINGW_INLINE_OVERRIDE_ASM_CALL 1
#else
# define __MINGW_INLINE_OVERRIDE_ASM_CALL 0
#endif
Which alternative do you prefer?
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
