desktop-packages team mailing list archive

[Renato Golin <1488254@xxxxxxxxxxxxxxxxxx>]

(In reply to comment #28)
> The incompatibility was introduced by gcc's "automatic tagging of functions
> and variables with tagged types where the tags are not already reflected in
> the mangled name".

So, the original patch would allow the tagging, but this patch made it
automatic and compulsory?

I think one of the issues from the original patch is that we didn't need
it until it was made compulsory, and that decision was taken and there
was little discussion on the effects for Clang until this week, when all
release tests started failing.

This was a major cock-up from all of us (me included). I'm not trying to
blame people, just understand who should have what responsibility, so
that we make sure this doesn't happen again.


> Now every library function with e.g a std::string return type causes linker
> errors.

On AArch64, we don't always get linker errors, but we do get
segmentation fault on:

#include <iostream>
int main() { std::cout << "Hello World" << std::endl; }

On Debian unstable and I think the unreleased version of Ubuntu. RedHat,
Suse and others may have the same trouble. I was told this was related
to the same ABI tag problem, and reading that they've also changed the
object layout (not just mangling), this makes a lot of sense. I haven't
investigated more than that, I'm afraid.


> To solve this issue, Clang only would have to implement the return type ABI
> tagging. All other ABI tags are irrelevant AFAIK.

If I read correctly, one of the emails says this is only temporary, and
wouldn't show in the final object, since C++ doesn't distinguish return
types, that's most useful.

That seems to imply that we'd need IR representations, in addition to
mangling, and that the back-ends will have to carry it all the way to
assembly (but not object) output, which doesn't seem like a small
change. If this needs to stay until emission, we can't use metadata, it
needs to be a full-fledged IR construct.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to llvm-toolchain-3.6 in Ubuntu.
https://bugs.launchpad.net/bugs/1488254

Title:
  clang++ no longer ABI-compatible with g++

Status in LLVM:
  Confirmed
Status in llvm-toolchain-3.6 package in Ubuntu:
  Confirmed

Bug description:
  $ cat foo.cc
  #include <string>
  std::string hello = "Hello, world!\n";
  $ cat bar.cc
  #include <string>
  #include <iostream>
  extern std::string hello;
  int main() {
      std::cout << hello;
      return 0;
  }
  $ g++ -c foo.cc && g++ foo.o bar.cc && ./a.out
  Hello, world!
  $ clang++ -c foo.cc && clang++ foo.o bar.cc && ./a.out
  Hello, world!
  $ g++ -c foo.cc && clang++ foo.o bar.cc && ./a.out
  /tmp/bar-34fb23.o: In function `main':
  bar.cc:(.text+0x14): undefined reference to `hello'
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  $ clang++ -c foo.cc && g++ foo.o bar.cc && ./a.out
  /tmp/ccqU38Mh.o: In function `main':
  bar.cc:(.text+0x5): undefined reference to `hello[abi:cxx11]'
  collect2: error: ld returned 1 exit status

  In practice, this means that many programs using C++ libraries other
  than libstdc++ fail to compile with clang++. For example, mosh fails
  with undefined references to
  google::protobuf::internal::empty_string_,
  google::protobuf::MessageLite::InitializationErrorString() const, and
  google::protobuf::MessageLite::SerializeAsString() const.

To manage notifications about this bug go to:
https://bugs.launchpad.net/llvm/+bug/1488254/+subscriptions