- parse abi_tag attribute
- emit abi tags in name Itanium Mangling
- try to emit the same tags as gcc5
Details
- Reviewers
stbuehler aaron.ballman majnemer rsmith
Diff Detail
- Repository
- rL LLVM
Event Timeline
Just for the record: substitution doesn't work yet (it should add available tags from the substitution, but doesn't).
This example shows the difference: my patch mangles T::F() as N::Name(N::__test::Result)::T::F[abi:test](N::__test::Result), but actually shouldn't emit the abi tag.
namespace N { inline namespace __test __attribute__((abi_tag("test"))) { struct Result { const char *str; }; } inline Result Name(Result p1) { struct T { Result F(Result p2) { struct S { Result F(Result p3) { static Result s3 = p3; return s3; } }; static Result s2 = S().F(p2); return s2; } }; static Result s1 = T().F(p1); return s1; } void F() { // instantiate Name() Name(Result()); } }
I can't figure out how to add code to someone else's Phabricator review, so sent it to the mailing list
instead: <http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151207/144636.html> "[PATCH] Re D12834 add gcc abi_tag support."
We have received a few reports of clang crashes after applying the abi_tag support patch to our llvm/clang package in Arch Linux.
Compiling
with clang++ -std=c++14 -c test.cc should trigger the segmentation fault due to (what I think is) a runaway recursion.I'm also attaching an excerpt from GDB that shows the loop in the execution:
HALP! :3
Why would you put a patch clearly marked as "needs review" into a distribution?!?!?!?!
In any case, the recursion source seems obvious to me, but I don't know how to add patches to this reviewboard item.
There's a "Commandeer Revision" action, that will let you take ownership of the diff. After you do that, you should be able to upload your own diff in the review.
We waited 6 months before switching to the new ABI in libstdc++. Ideally, we would have waited until the patch was reviewed and merged but did not want to wait much longer. I also (wrongly) considered the patch to be relative stable.
In any case, the recursion source seems obvious to me, but I don't know how to add patches to this reviewboard item.
If the correction is obvious as well and not very complex, would you mind sharing it?
What would make you believe this was stable?! This patch has known differences in ABI anyway.
In any case, the recursion source seems obvious to me, but I don't know how to add patches to this reviewboard item.
If the correction is obvious as well and not very complex, would you mind sharing it?
I see the recursion source, but I don't know if my fix would be "correct," as I do not know enough about the new ABI nor GCC's internals (and therefore cross-checking it) to ensure it will behave correctly. I'm erring on the side of caution for now.
lib/AST/ItaniumMangle.cpp | ||
---|---|---|
1119 | This looks bogus, should be writeAbiTags(qualifier) right? |
- disable dervied abi tags in some recursions to fix infinite recursions
- don't emit abi tags for NestedNameSpecifier::Identifier
integrate patch by Stephan Bergmann <sbergman@redhat.com>:
- Fix handling of abi_tag attribute on namespaces to match GCC behavior:
- Forbid the attribute on unnamed namespaces. (GCC merely produces a warning instead of an error for unnamed or non-inline namespaces, though.)
- When no tags are given for a (named, inline) namespace, use the namespace's name as tag.
The latest patch still applies (relatively cleanly) to Clang 3.7.x which is nice. The infinite recursion segfaults appear to be gone, thanks!
There are a few test failures which I assume will be need to be addressed later on:
I don't have the expertise to review the semantics of the attribute, but here are some cursory thoughts on the attribute itself.
include/clang/Basic/Attr.td | ||
---|---|---|
355 | The diagnostic doesn't match the subject -- "methods" refers to Objective-C methods, which should either be listed in the SubjectList or removed from the diagnostic. | |
357 | No new undocumented attributes, please -- you should add documentation to AttrDocs.td and link to it from here. | |
include/clang/Basic/DiagnosticSemaKinds.td | ||
4149 | Should quote 'abi_tag' in the diagnostic (here and below as well). Also, why an error instead of a warning and dropping the attribute from the declaration? Perhaps: 'abi_tag' attribute on %select{inline|anonymous}0 namespace ignored" as a warning, and remove the below diagnostic entirely? | |
lib/Sema/SemaDeclAttr.cpp | ||
4456 | Why a vector of std::string instead of StringRef? | |
4476 | Indentation is incorrect; also, elide braces for single statement ifs. | |
4479 | Comments should be complete sentences (with capitalization and punctuation); here and elsewhere. |
I think Sema part should be exacted to separate patch and committed first after fixing Aaron's comments. Mangling part requires more work and much more tests. I'm still looking what actually GCC does and how it can be re-implemented in Clang without calling mangler twice.
lib/Sema/SemaDeclAttr.cpp | ||
---|---|---|
4450 | Nit, all args fits to single line and the whole function needs clang-format. |
Hi Stefan,
What are your plans about this patch? The patch has number of comments about Sema part from Aaron and me but in general there are no major issues with Sema for the attribute.
As for mangling part I think recursive approach looks reasonable because alternative implementation will require re-implementation significant part of name mangling just to calculate abi_tags for types. So your approach minimizes code duplication. I made following changes in your patch
:- rebase on top-of-the-tree
- fixed all failing tests (now check-clang has no unexpected fails)
- fixed issue with mangling for variables in global namespace with abi_tags
- partially fixed style/clang-format issues
- added more tests on abi_tags (used the newest GCC mangling for templates with Jason's patches from Jan 31, 2016)
If you are going to keep working on this patch, please integrate my patch in your patch. If you are not going to keep working on this patch, please let me know.
Thanks,
Dmitry Polukhin
Software Engineer
Intel Compiler Team
Hello, folks!
Sorry for bothering you because I'm just user of clang 3.8 and gcc 5.3 and haven't any experience in compiler development. But I've hit issue mentioned in this ticket.
I've C++ 11 enabled libraries (gRPC, protobuf, bson and mongodb c++ 11 client) in my project which are compiled with gcc 5.3. So I've tried to move to clang for this project for testing purposes (and awesome clang static analyzer!).
But actually it becoming nightmare because I need to rebuild each C++ 11 library for both compilers because of this issue :(
Could you look on this issue and offer some workaround? Will be fine to have support of already created by gcc 5.3 tags.
Hi Pavel,
Code review is not a good place to discuss such type of things. There is no
really good workaround for this issue if you already have libraries built
with C++ 11 and GCC configured to use abi_tag. But if you are doing it only
for testing and you are willing to build Clang yourself, you could try to
get top of the tree Clang and apply this http://reviews.llvm.org/D18035. If
you do so, please report any issues with abi_tag to the patch or to me
directly. I tested patch http://reviews.llvm.org/D18035 on tests and small
things only so testing on something bigger will be helpful.
The diagnostic doesn't match the subject -- "methods" refers to Objective-C methods, which should either be listed in the SubjectList or removed from the diagnostic.