Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what gcc did on 4.7. The timing is also good as we will not build with 4.6 anymore when we switch to c++11. Is anyone depending on targeting the 4.6 mingw ABI even after we drop support for building with 4.6? Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.patch Type: application/octet-stream Size: 1093 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131209/8da60ccf/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch Type: application/octet-stream Size: 3570 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131209/8da60ccf/attachment-0001.obj>
It's worth noting that gcc chose *not* to support any ABI changing flags. I'm in favor of avoiding flags here. We can simply document that clang 3.3 and earlier works with gcc 4.6 and earlier, and clang 3.4+ works with gcc 4.7+. On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscall calling convention to methods by > default. > > I think the last bug blocking us to support the new abi has just been > fixed. The question now is how to switch. > > The attached patches simply switch llvm and clang to the new ABI. This > is similar to what gcc did on 4.7. The timing is also good as we will > not build with 4.6 anymore when we switch to c++11. > > Is anyone depending on targeting the 4.6 mingw ABI even after we drop > support for building with 4.6? > > Cheers, > Rafael >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131209/8723ce0d/attachment.html>
I'm with Reid. Yaron 2013/12/10 Reid Kleckner <rnk at google.com>> It's worth noting that gcc chose *not* to support any ABI changing flags. > > I'm in favor of avoiding flags here. We can simply document that clang > 3.3 and earlier works with gcc 4.6 and earlier, and clang 3.4+ works with > gcc 4.7+. > > > On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola < > rafael.espindola at gmail.com> wrote: > >> Mingw switched abis with the release of gcc 4.7 >> (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now >> mingw (like msvc) given thiscall calling convention to methods by >> default. >> >> I think the last bug blocking us to support the new abi has just been >> fixed. The question now is how to switch. >> >> The attached patches simply switch llvm and clang to the new ABI. This >> is similar to what gcc did on 4.7. The timing is also good as we will >> not build with 4.6 anymore when we switch to c++11. >> >> Is anyone depending on targeting the 4.6 mingw ABI even after we drop >> support for building with 4.6? >> >> Cheers, >> Rafael >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/adb388c4/attachment.html>
+1. In case of ARM e.g. we can make sure we won't link stuff with incompatible ABIs, but not here.... On Tue, Dec 10, 2013 at 5:28 AM, Reid Kleckner <rnk at google.com> wrote:> It's worth noting that gcc chose *not* to support any ABI changing flags. > > I'm in favor of avoiding flags here. We can simply document that clang 3.3 > and earlier works with gcc 4.6 and earlier, and clang 3.4+ works with gcc > 4.7+. > > > On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> Mingw switched abis with the release of gcc 4.7 >> (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now >> mingw (like msvc) given thiscall calling convention to methods by >> default. >> >> I think the last bug blocking us to support the new abi has just been >> fixed. The question now is how to switch. >> >> The attached patches simply switch llvm and clang to the new ABI. This >> is similar to what gcc did on 4.7. The timing is also good as we will >> not build with 4.6 anymore when we switch to c++11. >> >> Is anyone depending on targeting the 4.6 mingw ABI even after we drop >> support for building with 4.6? >> >> Cheers, >> Rafael > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
For the current project I'm working on (https://github.com/mono/CppSharp) having the flags to change the ABI based on a GCC version would be ideal. If there are no flags, this means we must implement some logic to change the calling conventions of methods manually to how they were pre-4.7. Should not be a lot of work but it'd be best to contain all the C++ ABI details inside Clang itself. It's also likely the ABI will change in the future, so this would allow to support those changes while maintaining compatibility with earlier GCC versions. By the way, we've been working around this MinGW ABI thiscall issue for a couple weeks so thanks for fixing it. On Tue, Dec 10, 2013 at 1:28 AM, Reid Kleckner <rnk at google.com> wrote:> It's worth noting that gcc chose *not* to support any ABI changing flags. > > I'm in favor of avoiding flags here. We can simply document that clang > 3.3 and earlier works with gcc 4.6 and earlier, and clang 3.4+ works with > gcc 4.7+. > > > On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola < > rafael.espindola at gmail.com> wrote: > >> Mingw switched abis with the release of gcc 4.7 >> (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now >> mingw (like msvc) given thiscall calling convention to methods by >> default. >> >> I think the last bug blocking us to support the new abi has just been >> fixed. The question now is how to switch. >> >> The attached patches simply switch llvm and clang to the new ABI. This >> is similar to what gcc did on 4.7. The timing is also good as we will >> not build with 4.6 anymore when we switch to c++11. >> >> Is anyone depending on targeting the 4.6 mingw ABI even after we drop >> support for building with 4.6? >> >> Cheers, >> Rafael >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- João Matos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/22a25d0d/attachment.html>
On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscall calling convention to methods by > default. > > I think the last bug blocking us to support the new abi has just been > fixed. The question now is how to switch.I'm still seeing some test failures. For example, CXX/class.access/p6.cpp fails if I apply your patch and run with -triple i686-pc-mingw32: $ "D:/src/llvm/build.release/bin/./clang.EXE" "-cc1" -triple i686-pc-mingw32 "-internal-isystem" "D:\src\llvm\build.release\bin\..\lib\clang\3.4\include" "-fsyntax-only" "-verify" "D:\src\llvm\tools\clang\test\CXX\class.access\p6.cpp" error: 'error' diagnostics expected but not seen: File D:\src\llvm\tools\clang\test\CXX\class.access\p6.cpp Line 180: 'operator void *(class test8::A::*)(void) const' is a private member of 'test8::A' error: 'error' diagnostics seen but not expected: File D:\src\llvm\tools\clang\test\CXX\class.access\p6.cpp Line 180: 'operator void *(class test8::A::*)(void) __attribute__((thiscall)) const' is a private member of 'test8::A' 2 errors generated. There are a handful other tests failing in the same way. It would be nice if we could make the TypePrinter not print the calling convention if it's the default one for the ABI, but TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ - Hans
I'll look into this. I think we should just print the unadjusted type if we have an adjusted function type under a member pointer. This should be an easy type printer fix. On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote:> On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: > > Mingw switched abis with the release of gcc 4.7 > > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > > mingw (like msvc) given thiscall calling convention to methods by > > default. > > > > I think the last bug blocking us to support the new abi has just been > > fixed. The question now is how to switch. > > I'm still seeing some test failures. For example, > CXX/class.access/p6.cpp fails if I apply your patch and run with > -triple i686-pc-mingw32: > > $ "D:/src/llvm/build.release/bin/./clang.EXE" "-cc1" -triple > i686-pc-mingw32 "-internal-isystem" > "D:\src\llvm\build.release\bin\..\lib\clang\3.4\include" > "-fsyntax-only" "-verify" > "D:\src\llvm\tools\clang\test\CXX\class.access\p6.cpp" > error: 'error' diagnostics expected but not seen: > File D:\src\llvm\tools\clang\test\CXX\class.access\p6.cpp Line 180: > 'operator void *(class test8::A::*)(void) const' is a private member > of 'test8::A' > error: 'error' diagnostics seen but not expected: > File D:\src\llvm\tools\clang\test\CXX\class.access\p6.cpp Line 180: > 'operator void *(class test8::A::*)(void) __attribute__((thiscall)) > const' is a private member of 'test8::A' > 2 errors generated. > > There are a handful other tests failing in the same way. > > It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ > > - Hans > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/81cee12c/attachment.html>
> There are a handful other tests failing in the same way. > > It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/They are all TypePrinter failures like this one? If so I would say we should not block on it since it is a small QOI issue. On the other hand Reid says it should be an easy fix, so we can wait a bit. Cheers, Rafael
On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote:> It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ >Does this patch fix any failures for you? It doesn't fix that test case, unfortunately. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/ffd7b891/attachment.html> -------------- next part -------------- diff --git a/lib/AST/TypePrinter.cpp b/lib/AST/TypePrinter.cpp index 082d027..cdfc90b 100644 --- a/lib/AST/TypePrinter.cpp +++ b/lib/AST/TypePrinter.cpp @@ -399,10 +399,16 @@ void TypePrinter::printMemberPointerBefore(const MemberPointerType *T, raw_ostream &OS) { IncludeStrongLifetimeRAII Strong(Policy); SaveAndRestore<bool> NonEmptyPH(HasEmptyPlaceHolder, false); - printBefore(T->getPointeeType(), OS); + + // Suppress the printing of implied calling conventions. + QualType Pointee = T->getPointeeType(); + if (const AdjustedType *AT = dyn_cast<AdjustedType>(Pointee)) + Pointee = AT->getOriginalType(); + + printBefore(Pointee, OS); // Handle things like 'int (Cls::*A)[4];' correctly. // FIXME: this should include vectors, but vectors use attributes I guess. - if (isa<ArrayType>(T->getPointeeType())) + if (isa<ArrayType>(Pointee)) OS << '('; PrintingPolicy InnerPolicy(Policy); @@ -415,11 +421,17 @@ void TypePrinter::printMemberPointerAfter(const MemberPointerType *T, raw_ostream &OS) { IncludeStrongLifetimeRAII Strong(Policy); SaveAndRestore<bool> NonEmptyPH(HasEmptyPlaceHolder, false); + + // Suppress the printing of implied calling conventions. + QualType Pointee = T->getPointeeType(); + if (const AdjustedType *AT = dyn_cast<AdjustedType>(Pointee)) + Pointee = AT->getOriginalType(); + // Handle things like 'int (Cls::*A)[4];' correctly. // FIXME: this should include vectors, but vectors use attributes I guess. - if (isa<ArrayType>(T->getPointeeType())) + if (isa<ArrayType>(Pointee)) OS << ')'; - printAfter(T->getPointeeType(), OS); + printAfter(Pointee, OS); } void TypePrinter::printConstantArrayBefore(const ConstantArrayType *T,
Maybe we should also change the stack probing code. I think ___chkstk_ms is used since gcc 4.6. It simplifies the prologue generation code a bit. Regards, Kai On 10.12.2013 02:18, Rafael Espíndola wrote:> Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscall calling convention to methods by > default. > > I think the last bug blocking us to support the new abi has just been > fixed. The question now is how to switch. > > The attached patches simply switch llvm and clang to the new ABI. This > is similar to what gcc did on 4.7. The timing is also good as we will > not build with 4.6 anymore when we switch to c++11. > > Is anyone depending on targeting the 4.6 mingw ABI even after we drop > support for building with 4.6? > > Cheers, > Rafael > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- diff --git a/lib/Target/X86/X86FrameLowering.cpp b/lib/Target/X86/X86FrameLowering.cpp index 142e60b..0c5209c 100644 --- a/lib/Target/X86/X86FrameLowering.cpp +++ b/lib/Target/X86/X86FrameLowering.cpp @@ -608,14 +608,12 @@ void X86FrameLowering::emitPrologue(MachineFunction &MF) const { // virtual memory manager are allocated in correct sequence. if (NumBytes >= 4096 && STI.isOSWindows() && !STI.isTargetMacho()) { const char *StackProbeSymbol; - bool isSPUpdateNeeded = false; if (Is64Bit) { - if (STI.isTargetCygMing()) - StackProbeSymbol = "___chkstk"; - else { + if (STI.isTargetCygMing()) { + StackProbeSymbol = "___chkstk_ms"; + } else { StackProbeSymbol = "__chkstk"; - isSPUpdateNeeded = true; } } else if (STI.isTargetCygMing()) StackProbeSymbol = "_alloca"; @@ -657,15 +655,15 @@ void X86FrameLowering::emitPrologue(MachineFunction &MF) const { .addReg(X86::EFLAGS, RegState::Define | RegState::Implicit) .setMIFlag(MachineInstr::FrameSetup); - // MSVC x64's __chkstk does not adjust %rsp itself. - // It also does not clobber %rax so we can reuse it when adjusting %rsp. - if (isSPUpdateNeeded) { + if (Is64Bit) { + // MSVC x64's __chkstk and cygwin/mingw's ___chkstk_ms do not adjust %rsp + // themself. It also does not clobber %rax so we can reuse it when + // adjusting %rsp. BuildMI(MBB, MBBI, DL, TII.get(X86::SUB64rr), StackPtr) .addReg(StackPtr) .addReg(X86::RAX) .setMIFlag(MachineInstr::FrameSetup); } - if (isEAXAlive) { // Restore EAX MachineInstr *MI = addRegOffset(BuildMI(MF, DL, TII.get(X86::MOV32rm), diff --git a/test/CodeGen/X86/win64_alloca_dynalloca.ll b/test/CodeGen/X86/win64_alloca_dynalloca.ll index aff5305..a6b6536 100644 --- a/test/CodeGen/X86/win64_alloca_dynalloca.ll +++ b/test/CodeGen/X86/win64_alloca_dynalloca.ll @@ -12,11 +12,11 @@ entry: %buf0 = alloca i8, i64 4096, align 1 -; ___chkstk must adjust %rsp. +; ___chkstk_ms does not adjust %rsp. ; M64: movq %rsp, %rbp ; M64: $4096, %rax -; M64: callq ___chkstk -; M64-NOT: %rsp +; M64: callq ___chkstk_ms +; M64: subq %rax, %rsp ; __chkstk does not adjust %rsp. ; W64: movq %rsp, %rbp diff --git a/test/CodeGen/X86/win_chkstk.ll b/test/CodeGen/X86/win_chkstk.ll index 3f522ea..0c02c1a 100644 --- a/test/CodeGen/X86/win_chkstk.ll +++ b/test/CodeGen/X86/win_chkstk.ll @@ -17,7 +17,7 @@ entry: ; WIN_X32: calll __chkstk ; WIN_X64: callq __chkstk ; MINGW_X32: calll __alloca -; MINGW_X64: callq ___chkstk +; MINGW_X64: callq ___chkstk_ms ; LINUX-NOT: call __chkstk %array4096 = alloca [4096 x i8], align 16 ; <[4096 x i8]*> [#uses=0] ret i32 0 @@ -36,7 +36,7 @@ entry: ; WIN_X64: ret ; MINGW_X64: # BB#0: -; MINGW_X64-NOT: callq _alloca +; MINGW_X64-NOT: callq ___chkstk_ms ; MINGW_X64: ret ; LINUX: # BB#0: @@ -53,7 +53,7 @@ entry: ; WIN_X32: calll __chkstk ; WIN_X64: callq __chkstk ; MINGW_X32: calll __alloca -; MINGW_X64: callq ___chkstk +; MINGW_X64: callq ___chkstk_ms ; LINUX-NOT: call __chkstk %array4096 = alloca [4096 x i8], align 16 ; <[4096 x i8]*> [#uses=0] ret i32 0
On 11 December 2013 05:41, Kai Nacke <kai.nacke at redstar.de> wrote:> Maybe we should also change the stack probing code. I think ___chkstk_ms is > used since gcc 4.6. It simplifies the prologue generation code a bit.I just checked gcc 4.6 and looks like you are right, it uses ___chkstk_ms. LGTM. We should probably commit this first, since it is common for gcc 4.6 and newer. Cheers, Rafael
Maybe Matching Threads
- [LLVMdev] Switching to the new MingW ABI
- [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
- [LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
- invalid code generated on Windows x86_64 using skylake-specific features
- [LLVMdev] Cygwin llvm-gcc regression