[cfe-dev] GCC binary compatibility / bug 23034

[Axel Naumann]

Hi John,

see below...

On 08.04.2015 22:10, John McCall wrote:
>
>> On Apr 8, 2015, at 9:10 AM, David Blaikie <dblaikie at gmail.com
>> <mailto:dblaikie at gmail.com>> wrote:
>>
>>
>>
>> On Wed, Apr 8, 2015 at 7:10 AM, Axel Naumann <Axel.Naumann at cern.ch
>> <mailto:Axel.Naumann at cern.ch>> wrote:
>>
>>     Hi,
>>
>>     Regarding <https://llvm.org/bugs/show___bug.cgi?id=23034
>>     <https://llvm.org/bugs/show_bug.cgi?id=23034>> - is the intent
>>     (still?) to be binary compatible with GCC?
>>
>>
>> ABI compatible, yes.
>>
>>     I.e. is this a bug or is this something that we'll have to try to
>>     solve on our side?
>>
>>
>> If you have a function defined in GCC that isn't callable from Clang
>> (or the other way around) that's a bug, but it doesn't indicate where
>> the bug is. It could be in GCC, Clang, or the ABI specification itself
>> (the ABI might be underspecified, vague, or contradictory). Also the
>> bug may've been fixed (sometimes this is due to an ABI fix - ABI spec
>> gets updated, one compiler takes the fix while the other lags a bit
>> potentially)
>>
>>     It's pretty visible for us because any call with std::string
>>     temporaries to map<string,...>::op[](string&&__) across the linker
>>     causes it and we seem to like those a lot :-(
>>
>>     I checked with r204218 and it seems to fail the same way, so if
>>     it's an issue it's not a new one (on clang's side).
>>
>>     And finally: should this go to llvm's bugs or stay with clang's?
>>
>>
>> I'm not sure - would depend on where the bug is & I don't know enough
>> about this stuff to say.
>>
>> A reduced test case would be helpful (the smallest standalone program
>> (no headers, etc) that demonstrates the inconsistency).
>
> The test case in the PR is interesting.  Clang thinks that the result of
> forward_as_tuple<std::string> should be returned directly, but GCC
> thinks it should be returned indirectly.  The return type is apparently
> a std::tuple<std::string&&>; without looking it up in the libstdc++
> sources, I assume that has a non-static data member of type
> std::string&& and that its copy and move constructors are explicitly
> defaulted.  I think the standard itself may have wavered about this, but
> the current state is that the copy constructor should be defined as
> deleted, the move constructor is okay, and that both are technically
> trivial.
>
> Anyway, it is not surprising that you can find Clang and GCC versions
> that disagree about the ABI there.  You can almost surely find two Clang
> versions that disagree about the ABI there.  The ABI rule we’ve settled
> on is that this should be returned directly, since all the copy and move
> constructors are either deleted or trivial and at least one (the move
> constructor) is not deleted.  It is likely that you are using a version
> of GCC that does not implement this rule correctly yet.

It took me a while to get the GCCs I wanted. I can now confirm that this 
fails with GCC 4.8.2, GCC 4.9.1 and GCC 5-20150405 (with their 
respective libstdc++). I don't see which version could work...

Shall I continue to reduce the example, would that help?

I can also test your hypothesis by switching the behavior of clang - if 
you can point me to where this direct versus indirect return happens.

Cheers, Axel