[cfe-dev] GCC binary compatibility / bug 23034

[John McCall]

> On Apr 8, 2015, at 9:10 AM, David Blaikie <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.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150408/c5614b5a/attachment.html>