assigned to @majnemer

If I understand the problem, even old GCCs will have such compatibility issues.

So, what GCC 5 is leading to, is a system that no other compiler can coexist without supporting abi_tags. This is bad not just for Clang, but for anyone experimenting with GCC 5 on a system based on 4.x, or reverting the compiler to work around 5.0 bugs.

If GCC 5 cannot work alongside compilers that don't support abi_tag, than maybe the abi_tag implementation needs to be reviewed, and rewritten so that they do.

I've added a few people to the bug, as this looks like a watershed moment. I can't grasp the full extent of the problem right now, but I'm hoping that Clang folks are already aware of the changes in libstdc++ and have a plan. :)

I'd also like to make sure we don't move away from libstdc++ just because of that. We need to support all mainstream C++ libraries.

David has started looking into this. Apparently there are many implementation bugs on the GCC side (in addition to all the other problems with this attribute), and it's not yet clear how many of them we'll need to be compatible with.

Isn't this precisely the kind of thing cxx-abi-dev exists to make saner? (Or would have, if it had been used).

Is there any update on this? The current ABI incompatibility between the latest released versions of gcc and clang in their default configurations is very unfortunate.

Any news in this issue?
last real comment was from june and that near 3 months ago.

first attempt to add abi_tag support
As debian testing now moved to the new gcc abi and I still want to be able to use clang I tried patching it myself.

Certainly not perfect, and you'll notice some places where I am uncertain whether abi tags need to be emitted in the name mangling, and I wasn't able to get the NamedDecl pointer for the emitted identifier.

Patch was created against http://llvm.org/svn/llvm-project/cfe/trunk 246931.

second attempt to add abi_tag
I came up with a list of various tests and compared the results.. and worked hard to improve the patch :)

http://files.stbuehler.de/test-itanium-mangle.html shows the test results (produced with http://files.stbuehler.de/test-itanium-mangle.sh). Some of the mangling results from gcc could also be considered completely broken (unnecessary emitted tags, missing tags in guard variables).

I fear the performance of the patch might be less than optimal though.

Please post your patch to cfe-commits@lists.llvm.org for review; very few people will see it here.

abi-tag patch version 3

document abi-tag mangling

abi-tag patch version 4

Tracking my patch now in http://reviews.llvm.org/D12834

*** Bug llvm/llvm-bugzilla-archive#24844 has been marked as a duplicate of this bug. ***

*** Bug llvm/llvm-bugzilla-archive#25656 has been marked as a duplicate of this bug. ***

Any news on this? This is blocking any recent Linux distribution.

I tried the "abi-tag patch version 4" attachment, and it appears to introduce some compiler crashes under 'make check-all'. Try out test/CodeGenCXX/static-local-in-local-class.cpp and you appear to get unbounded recursion:

$ gdb --args /home/steven/Development/llvm/build/Release/bin/clang -cc1 -internal-isystem /home/steven/Development/llvm/build/Release/bin/../lib/clang/3.7.0/include -nostdsysteminc -triple x86_64-linux -fblocks -emit-llvm -o - /home/steven/Development/llvm/tools/clang/test/CodeGenCXX/static-local-in-local-class.cpp -std=c++1y
[...]
(gdb) bt
[...]
#​26382 0x00000000014814c3 in (anonymous namespace)::CXXNameMangler::mangleLocalName(clang::Decl const*, llvm::SmallVector<llvm::StringRef, 4u> const*, bool) ()
#​26383 0x0000000001481ef7 in (anonymous namespace)::CXXNameMangler::mangleNameWithAbiTags(clang::NamedDecl const*, llvm::SmallVector<llvm::StringRef, 4u> const*, bool) ()
#​26384 0x000000000147c030 in (anonymous namespace)::CXXNameMangler::mangleName(clang::NamedDecl const*, bool) ()
#​26385 0x0000000001479308 in (anonymous namespace)::CXXNameMangler::mangleType(clang::QualType) ()
#​26386 0x000000000147cb74 in (anonymous namespace)::CXXNameMangler::mangleFunctionEncoding(clang::FunctionDecl const*, bool) ()
#​26387 0x00000000014814c3 in (anonymous namespace)::CXXNameMangler::mangleLocalName(clang::Decl const*, llvm::SmallVector<llvm::StringRef, 4u> const*, bool) ()
#​26388 0x0000000001481ef7 in (anonymous namespace)::CXXNameMangler::mangleNameWithAbiTags(clang::NamedDecl const*, llvm::SmallVector<llvm::StringRef, 4u> const*, bool) ()
#​26389 0x000000000147c030 in (anonymous namespace)::CXXNameMangler::mangleName(clang::NamedDecl const*, bool) ()
#​26390 0x0000000001479308 in (anonymous namespace)::CXXNameMangler::mangleType(clang::QualType) ()
#​26391 0x000000000147cb74 in (anonymous namespace)::CXXNameMangler::mangleFunctionEncoding(clang::FunctionDecl const*, bool) ()
#​26392 0x00000000014814c3 in (anonymous namespace)::CXXNameMangler::mangleLocalName(clang::Decl const*, llvm::SmallVector<llvm::StringRef, 4u> const*, bool) ()
#​26393 0x0000000001481ef7 in (anonymous namespace)::CXXNameMangler::mangleNameWithAbiTags(clang::NamedDecl const*, llvm::SmallVector<llvm::StringRef, 4u> const*, bool) ()
#​26394 0x000000000147c030 in (anonymous namespace)::CXXNameMangler::mangleName(clang::NamedDecl const*, bool) ()
#​26395 0x0000000001479308 in (anonymous namespace)::CXXNameMangler::mangleType(clang::QualType) ()
#​26396 0x000000000147cb74 in (anonymous namespace)::CXXNameMangler::mangleFunctionEncoding(clang::FunctionDecl const*, bool) ()
#​26397 0x0000000001481367 in (anonymous namespace)::ItaniumMangleContextImpl::mangleCXXName(clang::NamedDecl const*, llvm::raw_ostream&) ()
#​26398 0x00000000009e9eae in clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) ()
#​26399 0x00000000009eb14a in clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl, llvm::Type*, bool, bool) ()
#​26400 0x0000000000abf7c0 in clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(clang::CallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, bool, clang::NestedNameSpecifier*, bool, clang::Expr const*) ()
#​26401 0x0000000000abfe63 in clang::CodeGen::CodeGenFunction::EmitCXXOperatorMemberCallExpr(clang::CXXOperatorCallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot) ()
#​26402 0x0000000000ab4d3f in clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) ()
#​26403 0x0000000000ab4f7a in clang::CodeGen::CodeGenFunction::EmitCallExprLValue(clang::CallExpr const*) ()
#​26404 0x0000000000ab1a56 in clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) ()
#​26405 0x0000000000ab1de9 in clang::CodeGen::CodeGenFunction::EmitCastLValue(clang::CastExpr const*) ()
#​26406 0x0000000000ab1a3e in clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) ()
#​26407 0x0000000000abf635 in clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(clang::CallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, bool, clang::NestedNameSpecifier*, bool, clang::Expr const*) ()
#​26408 0x0000000000abfe63 in clang::CodeGen::CodeGenFunction::EmitCXXOperatorMemberCallExpr(clang::CXXOperatorCallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot) ()
#​26409 0x0000000000ab4d3f in clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) ()
#​26410 0x00000000006959fa in (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) ()
#​26411 0x0000000000ad7c0c in (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) ()
#​26412 0x0000000000ad88c0 in clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) ()
#​26413 0x00000000009b4f44 in clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) ()
#​26414 0x00000000009b68db in clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) ()
#​26415 0x00000000009b6c0f in clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) ()
#​26416 0x00000000009d45d2 in clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&, clang::Stmt const*) ()
#​26417 0x00000000009dab03 in clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) ()
#​26418 0x00000000009eb321 in clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) ()
#​26419 0x00000000009f50f3 in clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) ()
#​26420 0x00000000009f5a80 in clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) ()
#​26421 0x00000000009f6410 in clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.3064] [clone .constprop.3087] ()
#​26422 0x00000000009f672f in clang::CodeGen::CodeGenModule::EmitNamespace(clang::NamespaceDecl const*) ()
#​26423 0x00000000009f626d in clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.3064] [clone .constprop.3087] ()
#​26424 0x000000000097f3b3 in (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ()
#​26425 0x000000000096c14c in clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) ()
#​26426 0x0000000000b46396 in clang::ParseAST(clang::Sema&, bool, bool) ()
#​26427 0x00000000007c87b6 in clang::FrontendAction::Execute() ()
#​26428 0x000000000079f699 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#​26429 0x00000000007874e3 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#​26430 0x0000000000781250 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#​26431 0x0000000000752e12 in main ()

I'm not going to treat this as a release blocker as it's more of a feature request than a regression.

I'd still be open to merge a fix for this (though it seems unlikely), but I won't treat it as a blocker.

I admit that adding this new functionality sounds more like a feature request than a bug. But as I understood it, LLVM/Clang claims to support GCC and its libraries with a minimum version required.
No user would expect there to be an maximum version requirement.
I see two possible ways here for the next release:

1. State that LLVM/Clang only works up to GCC 4.9.
2. Add this attribute to be compatible to the most recent GCC release (5.3) again.
   For future releases of LLVM/Clang this PR may as well be treated as a feature request IMHO.

-1 for this being considered a feature request.

It's blocking anyone from updating their OSs in our company, which isn't going to happen, so we'll likely have to switch everything back to g++ only.

I'm sure we're not the only ones.

But as I understood it, LLVM/Clang claims to support GCC
and its libraries with a minimum version required.

I don't think we do. Our community has always sent a strong message that we'll be compatible with what makes sense AND allows us enough time to implement on our own.

No user would expect there to be an maximum version requirement.

This doesn't make sense. We're not the same team, we can't possibly keep up with another community entirely AND develop our own software at instant speed.

If LLVM was a plugin to GCC, that could be true, but not necessarily so. Since it's not, this statement doesn't make sense.

I see two possible ways here for the next release:

1. State that LLVM/Clang only works up to GCC 4.9.

LLVM "is known to work" with GCC up to "M.N". We never claimed full compatibility, nor I think we ever will.

2. Add this attribute to be compatible to the most recent GCC release (5.3)
   again.

If it was that simple, it would have been added already.

From comments in this very thread, it seems GCC's own implementation had several bugs, and implementing a bug for bug copy would be very silly indeed.

I'm not going to treat this as a release blocker as it's more of a feature
request than a regression.

Since I upgraded to Ubuntu 15.10 I cannot build anymore with clang projects that include Boost (Ubuntu ships boost 1.58) because of this GCC 5 ABI changes.

The result is that I won't be able to use clang anymore till this issue gets fixed, making this a blocking issue.

This is a feature, not a bug. Features do not block releases.

It's a feature because it's new behaviour to be added to Clang, not a regression in an old behaviour. That GCC designed and implemented this and that Linux distributions took that and ran with it is irritating, but does not make it a release blocker.

Implementing a new feature is not a one line fix, it's not something that can be merged to the release branch quickly - it needs design (especially in this case!) and soak testing.

It's nigh-on impossible for this to be done for the release, and therefore it makes no sense to have it block the release IMHO.

This is a feature, not a bug. Features do not block releases.

It's a feature because it's new behaviour to be added to Clang, not a
regression in an old behaviour. That GCC designed and implemented this and
that Linux distributions took that and ran with it is irritating, but does
not make it a release blocker.

Implementing a new feature is not a one line fix, it's not something that
can be merged to the release branch quickly - it needs design (especially in
this case!) and soak testing.

It's nigh-on impossible for this to be done for the release, and therefore
it makes no sense to have it block the release IMHO.

James is right; we cannot block the release on the development of this feature.

Also, if you'd like to express your support for the development of this feature to the Clang/LLVM community, you'll need to do it on llvm-dev/cfe-dev, not here.

Following up on the Linaro Toolchain list[1], I found out a few facts:

1. This feature was implemented in GCC and libstdc++ in 2012, after discussions on the cauldron with distro representatives.

2. The feature is poorly documented, and may have changed behaviour until recently. I have no evidence of changes, is anyone does, please update.

3. The problem only started because distros have chosen GCC 5 as their default compilers for the current releases, which defaults to C++11.

4. The fact that GCC developers didn't liaise with Clang developers is a shame, but understandable. The real issue here is the fact that distro representatives took an executive decision to change the object layout of core C++ classes in libstdc++ and to change the ABI without worrying about other compilers.

If they has asked Clang folks about the ABI change, (and they did, see this thread), they would have known that the ABI behaviour was poorly documented and a moving target (as they did, look at this bug), and should have taken the decision to mitigate the problems.

In this case, I'd expect distro folks to be the middle-men between GCC and Clang and to make sure that both compilers work well on their new releases. If you look at this bug and all of those that were marked as duplicate, you'll see that both Debian and RedHat based distros knew that Clang still didn't have the feature they needed and why.

True, we could have been more informative and made explicit every detail on why it was hard to know what to implement, but as middle-men, I expected distros to be more pro-active towards unification and less pro-active towards changing the ABI.

[1] https://lists.linaro.org/pipermail/linaro-toolchain/2016-January/005457.html

Following up on the Linaro Toolchain list[1], I found out a few facts:

1. This feature was implemented in GCC and libstdc++ in 2012, after
   discussions on the cauldron with distro representatives.

No. It was implemented in April this year, shortly before the gcc-5 release.
I've pointed out compatibility issue immediately:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00153.html

2. The feature is poorly documented, and may have changed behaviour until
   recently. I have no evidence of changes, is anyone does, please update.

The were no behavioral changes at all after that patch went in.

3. The problem only started because distros have chosen GCC 5 as their
   default compilers for the current releases, which defaults to C++11.

No gcc-5 doesn't default to C++11 and the issue here has nothing to do with
C++98 vs. C++11.

Please try to get the facts strait, before posting long misleading replies.

No. It was implemented in April this year, shortly before the gcc-5 release.
I've pointed out compatibility issue immediately:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00153.html
(...)
The were no behavioral changes at all after that patch went in.

In the Linaro thread, Jim points out to the abi_tag patch from 2012. Your mention is about "significant changes to attribute abi_tag". I can't see how I was wrong.

No gcc-5 doesn't default to C++11 and the issue here has nothing to do with
C++98 vs. C++11.

Please try to get the facts strait, before posting long misleading replies.

This is what most of the documentation, email threads and conversations I had seem to point at. If you have a different opinion, than by all means, please share your knowledge.

Saying "it has nothing to do with" doesn't explain what it has to do with. I'm happy to be proven wrong here, as long as we get all the facts on the table. This bug doesn't seem to provide strong facts either.

No. It was implemented in April this year, shortly before the gcc-5 release.
I've pointed out compatibility issue immediately:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00153.html
(...)
The were no behavioral changes at all after that patch went in.

In the Linaro thread, Jim points out to the abi_tag patch from 2012. Your
mention is about "significant changes to attribute abi_tag". I can't see how
I was wrong.

No gcc-5 doesn't default to C++11 and the issue here has nothing to do with
C++98 vs. C++11.

Please try to get the facts strait, before posting long misleading replies.

This is what most of the documentation, email threads and conversations I
had seem to point at. If you have a different opinion, than by all means,
please share your knowledge.

Saying "it has nothing to do with" doesn't explain what it has to do with.
I'm happy to be proven wrong here, as long as we get all the facts on the
table. This bug doesn't seem to provide strong facts either.

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".
Before that patch (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01029.html)
both gcc and clang could use the new ABI without any problem.

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

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

No gcc-5 doesn't default to C++11 and the issue here has nothing to do with
C++98 vs. C++11.

Please try to get the facts strait, before posting long misleading replies.

This is what most of the documentation, email threads and conversations I
had seem to point at. If you have a different opinion, than by all means,
please share your knowledge.

The relevant issue is whether libstdc++'s _GLIBCXX_USE_CXX11_ABI is enabled by default, see https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html.

Hi Andrey,

Stefan [Bühler], do you plan to finish work on the patch? Do you need help
with code review? (I just added Aaron Ballman, who is code owner for
attributes).

I think the attributes part of the patch is quite good compared with
the mangling part... perhaps it should be split into a separate patch.

Regarding the mangling I'm not too happy with my patch. I don't understand
what most of the mangling code did before to actually know where
to insert the tagging code. This is C++ on a level I don't usually touch;
I'm not familiar with all the terms (,
, ...) and just keep guessing what they do.

Also I don't like using recursion to determine the inherited abi tags;
I think using temporary strings instead of directly writing to the stream
would solve this.

All in all I hoped to get some feedbacks how things are done or should
look like; I don't mind if someone else wants to take over and rewrite
the mangling :)

I planned looking at the original gcc code some day, but didn't get around
doing that either; maybe others can help with the documentation too (how
the abi tag mangling actually should look like). More "examples" certainly
wouldn't hurt either.

*** Bug llvm/llvm-bugzilla-archive#26401 has been marked as a duplicate of this bug. ***

"C++ PATCHes for abi_tag bugs" from Jason landed on gcc-patches, might be relevant.

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02374.html

Hum, both sound like serious bugs. I'm surprised all distros bought in the new ABI so eagerly.

Hi Stefan,

I think the attributes part of the patch is quite good compared with
the mangling part... perhaps it should be split into a separate patch.

Regarding the mangling I'm not too happy with my patch. I don't understand
what most of the mangling code did before to actually know where
to insert the tagging code. This is C++ on a level I don't usually touch;
I'm not familiar with all the terms (,
, ...) and just keep guessing what they do.

Also I don't like using recursion to determine the inherited abi tags;
I think using temporary strings instead of directly writing to the stream
would solve this.

All in all I hoped to get some feedbacks how things are done or should
look like; I don't mind if someone else wants to take over and rewrite
the mangling :)

Sure -- I will ask someone from Intel compiler team to handle mangling part. We are co-located with Intel GCC team, so it's easy for us to ask on intricacies of GCC implementation. :-)

I don't see attribute part of the patch to be reviewed, though -- we can help with this as well. (Though the real authority to approve it belongs to Aaron, so it's better to wait for his review (and ping if there is no reply from his after a week)).

Yours,
Andrey

I'll take a look to the change and will investigate why tests fail on the proposed patch. Failing tests are not abi_tag specific so it should be no changes on them.

Best regards,
Dmitry

Software Engineer
Intel Compiler Team

Hi Stefan,

This is an important issue in Clang and I would like to move on with patch http://reviews.llvm.org/D12834 (also see my last comment there). If you don't mind, I'll get your patch split it into smaller patches and start resolving reviewers comments. Please let me know if you have cycles and would like to keep working on this patch yourself.

Best regards,
Dmitry

Software Engineer
Intel Compiler Teaml

Hi Dmitry,

Hi Stefan,

This is an important issue in Clang and I would like to move on with patch
http://reviews.llvm.org/D12834 (also see my last comment there). If you
don't mind, I'll get your patch split it into smaller patches and start
resolving reviewers comments. Please let me know if you have cycles and
would like to keep working on this patch yourself.

I agree it is important, and it saddens me not having more time for this.

I'm perfectly fine with you (and others) taking this over - thanks!

regards,
Stefan

More bug-fixing for abi_tag on GCC side: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01293.html

Moreover, FreeBSD had to take many short-cuts to get rid of libstdc++ on the
base system, including making symlinks named after GNU libraries and tools
to LLVM libraries and tools, and the mapping is NOT 1-to-1. See the libc++ +
compiler-rt + libunwind vs. libgcc + libgcc_s + libgcc_eh connundrum.

There are not that many short-cuts and the primary issue was the desire to allow libstdc++ and libc++ to coexist. If it was just about using libc++, the issue is much simpler.

did this issue hit another roadblock ?

Jason Merrill said he'd write up some brief documentation for the attribute. We'd like to work from that rather than trying to guess GCC's intent from examples.

Jason Merrill said he'd write up some brief documentation for the attribute.
We'd like to work from that rather than trying to guess GCC's intent from
examples.

That's most helpful, thanks!

What about Dmitry's patch?

My patch for Sema part with of the attribute under review is here http://reviews.llvm.org/D17567

Status update:

• Sema part was committed http://reviews.llvm.org/D17567
• Mangler part was sent for review http://reviews.llvm.org/D18035

Best regards,
Dmitry

Software Engineer
Intel Compiler Team

This is becoming more and more of an important issue as distributions switch to building all their packages against GCC + libstdc++ 5 and plaster their libraries with [abi:cxx11] tags.

Since Ubuntu 15.10 Clang is basically unusable, every library making use of std::string has to be recompiled with -D_GLIBCXX_USE_CXX11_ABI=0, or with GCC/libstdc++ 4.9 in order to prevent linking errors.

Surprising that Dmitry's patch isn't receiving more attention.

Hi, any chance of an ETA guestimate / status update?

Cheers,
Tim

Hi, any chance of an ETA guestimate / status update?

Cheers,
Tim

The status is that there is a patch ready since 23rd March http://reviews.llvm.org/D18035#381281 and the author (and all users) is waiting for feedback from developers and/or for the patch to be merged.

Sounds like a chance for people to install the patch locally and start using it, and then provide feedback on any problems that crop up.

I've been using the patched version for the past couple of days, no issues so far.

But, I'm not one of the developers and don't know this code base and just because it seems to work doesn't mean it's correct yet. I'm just going to continue with what works well enough for me at the moment, with patience.

FWIW, Arch has applied both patches (as Andrey has stated in comment 37) and it is working fine.

abi_tag implementation was committed to Clang http://reviews.llvm.org/D18035 Please start testing on your apps and report issues.

abi_tag implementation was committed to Clang http://reviews.llvm.org/D18035
Please start testing on your apps and report issues.

Did this make clang 3.9? (Meta-question: what is an efficient way for me to find this out? Other bug trackers I'm used to have a "Target Milestone" field that's set when a fix is committed.)

Also, is there more work to do before this bug can be closed?

Did this make clang 3.9?

I guess so, it's mentioned in the 3.9 release notes. (My meta-question still applies for bugs that are not important enough to merit a mention in the release notes.)

search for the commit ID that should be referenced in the bug.

If the bug is new, just being lower than the date when the release branched means it went through.

If the commit is a backport, search for a release bug and see if the commit or the bug is linked as a dependency and in closed status.

I think this issue should be closed now and all reaming issues, if any, should be filed as separate trackers.

mentioned in issue llvm/llvm-bugzilla-archive#24844

mentioned in issue llvm/llvm-bugzilla-archive#25656

mentioned in issue llvm/llvm-bugzilla-archive#26401