Open Quuxplusone opened 9 years ago
Attached 011-gxx-abi-version.patch
(3960 bytes, text/plain): proposed patch
Please send your patch to the cfe-commits list for review, or better yet, upload it to reviews.llvm.org (please see http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface for instructions, and remember to add cfe-commits as a subscriber).
I think we can take this patch, but I'm opposed to going down the GCC path of wiring this flag up to codegen. The macro we define here is just a lie for compatibility with people that wrote some conservative ifdef checks.
(In reply to comment #2)
> I think we can take this patch, but I'm opposed to going down the GCC path
> of wiring this flag up to codegen. The macro we define here is just a lie
> for compatibility with people that wrote some conservative ifdef checks.
There is a new GNU C++ ABI in GCC >= 5.1.0. It is incompatible with the
old(er) GNU C++ ABI(s). Details here:
http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/
So, this ABI change will probably cause mangling and object layout
incompatibilities with clang's codegen.
I'm not trying to push for wiring this to codegen. Just explaining what's
going on.
We're holding off on using GCC 5.2.0's C++ Standard Library with clang,
because of this incompatibility.
(In reply to comment #3)
> There is a new GNU C++ ABI in GCC >= 5.1.0. It is incompatible with the
> old(er) GNU C++ ABI(s). Details here:
This has to do with breaking the ABI of libstdc++, not of the compiler, though,
right? Does -fabi-version factor into this change in a way that I'm not aware
of?
> We're holding off on using GCC 5.2.0's C++ Standard Library with clang,
> because of this incompatibility.
My understanding is that Clang just needs to implement __attribute__((abi_tag))
to make this work. No changes to record layout are required, and no manglings
for things without abi_tag should change.
(In reply to comment #4)
> (In reply to comment #3)
> > There is a new GNU C++ ABI in GCC >= 5.1.0. It is incompatible with the
> > old(er) GNU C++ ABI(s). Details here:
>
> This has to do with breaking the ABI of libstdc++, not of the compiler,
> though, right? Does -fabi-version factor into this change in a way that I'm
> not aware of?
I am not 100% certain yet because i haven't done a thorough digging inside
GCC. It's on my to-do list.
> > We're holding off on using GCC 5.2.0's C++ Standard Library with clang,
> > because of this incompatibility.
>
> My understanding is that Clang just needs to implement
> __attribute__((abi_tag)) to make this work. No changes to record layout are
> required, and no manglings for things without abi_tag should change.
Yes that's my understanding as well, as of today. However, and based on past
documented practice at GCC, they do change the mangling based on
__GCC_ABI_VERSION. For example, here:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
<QUOTE>
Version 3 corrects an error in mangling a constant address as a template
argument.
Version 4, which first appeared in G++ 4.5, implements a standard mangling for
vector types.
Version 5, which first appeared in G++ 4.6, corrects the mangling of attribute
const/volatile on function pointer types, decltype of a plain decl, and use of
a function parameter in the declaration of another parameter.
Version 6, which first appeared in G++ 4.7, corrects the promotion behavior of
C++11 scoped enums and the mangling of template argument packs,
const/static_cast, prefix ++ and –, and a class scope function used as a
template argument.
</QUOTE>
So, i'm not sure if this ABI change in GCC >= 5.1.0 is a forecaster of
more things to come, or not. GCC 4.9.0 introduced a new ABI Version,
namely Version 8. That worries me a bit, because it happened right before
GCC5.
I am going to/have to do more digging on this anyway, and will report back.
011-gxx-abi-version.patch
(3960 bytes, text/plain)