[cfe-dev] Does clang now emit [abi:cxx11] unconditionally when used with libstdc++?

[Richard Smith via cfe-dev]

I don't think it's a bug if they only applied abi_tag to entities like this
inline function that will be instantiated into every object file where
they're used and whose address is irrelevant. It's essentially
inconsequential whether you do the abi_tag mangling or not here, unless
you're actually mixing different ABI versions for the same type in the same
program. What this does mean is that you can't mix code compiled with
libstdc++4.9 with dual-ABI code from GCC 5 onwards, but that was already
the case in some corner cases due to other ABI breaks libstdc++
accidentally made prior to 5.0.

On Tue, Aug 16, 2016 at 10:50 AM, Dmitry Polukhin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I agree that it looks like a GCC bug that abi_tags are ignored in GCC
> 4.9.2. Anyway, if at some point we will want to implement it in Clang, I
> think right approach is to implement -fabi_version flags and, if specified
> ABI version is below GCC5, don't emit abi_tags in mangling.
>
> On Tue, Aug 16, 2016 at 1:05 AM, Richard Smith via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Mon, Aug 15, 2016 at 2:53 PM, Renato Golin via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> On 15 August 2016 at 22:43, Maria Gottschalk <gottschalk_maria at yahoo.de>
>>> wrote:
>>> > But actually, there were abi tags already in 4.9.2, e.g.
>>> >
>>> > But then gcc-4.9.2 doesn't emit any, while now clang-3.9.0 does!
>>>
>>> I'd risk say this is a bug in GCC. Or at least a pretty ugly
>>> implementation of something that should be simple.
>>>
>>
>> If it's only applied to an inline function, and that function did in fact
>> take an ABI break in libstdc++ 4.9.2, then this seems unproblematic. If
>> anything, our results will be marginally better than GCC 4.9.2's, because
>> we'll do the right thing when mixing libstdc++ 4.9.2 and an earlier
>> version. It looks like there is nothing to fix here.
>>
>>
>>> We can't be compatible with all versions of GCC on what attributes
>>> they support and the compile-time flags that they use. This just
>>> doesn't scale.
>>>
>>> In a way, if you don't want ABI tags, use Clang 3.8 or before. If you
>>> do, use Clang 3.9 or after.
>>>
>>> I'm not sure there's a better way of doing this and creating a
>>> compile-time flag just to imitate GCC seems like the wrong way to go,
>>> IMO.
>>>
>>> cheers,
>>> --renato
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160816/162427b0/attachment.html>