[LLVMdev] Switching to the new MingW ABI
João Matos
ripzonetriton at gmail.com
Tue Dec 10 06:16:02 PST 2013
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>
More information about the llvm-dev
mailing list