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 10 December 2013 09:16, João Matos <ripzonetriton at gmail.com> wrote:> 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.Because you must link with gcc 4.6 compiled libraries for now or is that a permanent thing? Cheers, Rafael
The tool uses Clang to parse the user's C/C++ code to get the calling conventions from the AST, so they need to match the ones in the compiled libraries to allow correct interop. If the user libraries were compiled with GCC 4.6 (which stills seems used by some MinGW distros) then once we upgrade to the latest Clang we'll start getting thiscall CC instead of the correct one used pre-4.7 for those libraries. If there was something like an "-fgcc-abi=4.6" flag we could pass to Clang, then it would provide us with the correct CCs for the given GCC version. If the community thinks that is undesirable for the project then we can work around it on our side, but it seems to me these details should be contained in Clang. On Tue, Dec 10, 2013 at 2:21 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> On 10 December 2013 09:16, João Matos <ripzonetriton at gmail.com> wrote: > > 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. > > Because you must link with gcc 4.6 compiled libraries for now or is > that a permanent thing? > > Cheers, > Rafael >-- João Matos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/833f5674/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Switching to the new MingW ABI
- [LLVMdev] Switching to the new MingW ABI
- [LLVMdev] Switching to the new MingW ABI
- [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]
- [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]