clang should emulate GCC's -fabi-version=<X>

[llvmbot]

Bugzilla Link	24685
Version	3.6
OS	Solaris
Attachments	proposed patch
Reporter	LLVM Bugzilla Contributor
CC	@hfinkel,@rnk

Extended Description

clang should emulate GCC's flag -fabi-version=, as documented here:

https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html

Proposed patch attached.

[llvmbot]

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

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.

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.

[rnk]

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.

[llvmbot]

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.

[rnk]

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.

[hfinkel]

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).