History log of /llvm-project-15.0.7/clang/lib/AST/ItaniumMangle.cpp (Results 1 – 25 of 514)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6
# 2e603c67 11-Jun-2022 Kazu Hirata <[email protected]>

[clang] Construct SmallVector with iterator ranges (NFC)


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# a1dcfb75 22-Mar-2022 Nathan Sidwell <[email protected]>

[clang] Module global init mangling

C++20 modules require emission of an initializer function, which is
called by importers of the module. This implements the mangling for
that function. It is the

[clang] Module global init mangling

C++20 modules require emission of an initializer function, which is
called by importers of the module. This implements the mangling for
that function. It is the one place the ABI exposes partition names in
symbols -- but fortunately only needed by other TUs of that same module.

Reviewed By: bruno

Differential Revision: https://reviews.llvm.org/D122741

show more ...


# 83c431fb 20-May-2022 Jon Chesterfield <[email protected]>

[amdgpu] Add amdgpu_kernel calling conv attribute to clang

Allows emitting define amdgpu_kernel void @func() IR from C or C++.

This replaces the current workflow which is to write a stub in opencl

[amdgpu] Add amdgpu_kernel calling conv attribute to clang

Allows emitting define amdgpu_kernel void @func() IR from C or C++.

This replaces the current workflow which is to write a stub in opencl that
calls an external C function implemented in C++ combined through llvm-link.

Calling the resulting function still requires a manual implementation of the
ABI from the host side. The primary application is for more rapid debugging
of the amdgpu backend by permuting a C or C++ test file instead of manually
updating an IR file.

Implementation closely follows D54425. Non-amd reviewers from there.

Reviewed By: yaxunl

Differential Revision: https://reviews.llvm.org/D125970

show more ...


# 75bb8152 29-Mar-2022 Matt Devereau <[email protected]>

[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang

Enable function attribute aarch64_sve_pcs at the C level, which correspondes to
aarch64_sve_vector_pcs at the LLVM IR level.

This requirement w

[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang

Enable function attribute aarch64_sve_pcs at the C level, which correspondes to
aarch64_sve_vector_pcs at the LLVM IR level.

This requirement was created by this addition to the ARM C Language Extension:
https://github.com/ARM-software/acle/pull/194

Differential Revision: https://reviews.llvm.org/D124998

show more ...


# 62501bc4 03-May-2022 Yaxun (Sam) Liu <[email protected]>

[NFC][CUDA][HIP] rework mangling number for aux target

CUDA/HIP needs to mangle for aux target. When mangling for aux target,
the mangler should use mangling number for aux target. Previously
in htt

[NFC][CUDA][HIP] rework mangling number for aux target

CUDA/HIP needs to mangle for aux target. When mangling for aux target,
the mangler should use mangling number for aux target. Previously
in https://reviews.llvm.org/D122734 a state was introduced in
ASTContext to let the mangler get mangling number for aux target
from ASTContext. This patch removes that state from ASTConext
and add an IsAux member to MangleContext to indicate that
the mangle context is for aux target. This reflects the reality that
the mangle context is created for mangling aux target and makes
ASTContext cleaner.

Reviewed by: Artem Belevich, Reid Kleckner

Differential Revision: https://reviews.llvm.org/D124842

show more ...


# fed7be09 02-May-2022 Harald van Dijk <[email protected]>

Mark identifier prefixes as substitutable

The Itanium C++ ABI says prefixes are substitutable. For most prefixes
we already handle this: the manglePrefix(const DeclContext *, bool) and
manglePrefix(

Mark identifier prefixes as substitutable

The Itanium C++ ABI says prefixes are substitutable. For most prefixes
we already handle this: the manglePrefix(const DeclContext *, bool) and
manglePrefix(QualType) overloads explicitly handles substitutions or
defer to functions that handle substitutions on their behalf. The
manglePrefix(NestedNameSpecifier *) overload, however, is different and
handles some cases implicitly, but not all. The Identifier case was not
handled; this change adds handling for it, as well as a test case.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D122663

show more ...


# 864752cf 21-Apr-2022 Haojian Wu <[email protected]>

[AST] QualifiedTemplateName::getTemplateDecl cleanup.

This is a followup cleanup of 1234b1c6d8113d50beef5801be607ad1d502b2f7

Differential Revision: https://reviews.llvm.org/D124238


# 6ba1b907 12-Apr-2022 Haojian Wu <[email protected]>

Reland "[AST] Add a new TemplateKind for template decls found via a using decl.""

This is the template version of https://reviews.llvm.org/D114251.

This patch introduces a new template name kind (U

Reland "[AST] Add a new TemplateKind for template decls found via a using decl.""

This is the template version of https://reviews.llvm.org/D114251.

This patch introduces a new template name kind (UsingTemplateName). The
UsingTemplateName stores the found using-shadow decl (and underlying
template can be retrieved from the using-shadow decl). With the new
template name, we can be able to find the using decl that a template
typeloc (e.g. TemplateSpecializationTypeLoc) found its underlying template,
which is useful for tooling use cases (include cleaner etc).

This patch merely focuses on adding the node to the AST.

Next steps:
- support using-decl in qualified template name;
- update the clangd and other tools to use this new node;
- add ast matchers for matching different kinds of template names;

Differential Revision: https://reviews.llvm.org/D123127

show more ...


# 95f0f69f 12-Apr-2022 Haojian Wu <[email protected]>

Revert "[AST] Add a new TemplateKind for template decls found via a using decl."

It breaks arm build, there is no free bit for the extra
UsingShadowDecl in TemplateName::StorageType.

Reverting it t

Revert "[AST] Add a new TemplateKind for template decls found via a using decl."

It breaks arm build, there is no free bit for the extra
UsingShadowDecl in TemplateName::StorageType.

Reverting it to build the buildbot back until we comeup with a fix.

This reverts commit 5a5be4044f0bceb71bb6a81f6955704691b389ed.

show more ...


# 5a5be404 11-Apr-2022 Haojian Wu <[email protected]>

[AST] Add a new TemplateKind for template decls found via a using decl.

This is the template version of https://reviews.llvm.org/D114251.

This patch introduces a new template name kind (UsingTempla

[AST] Add a new TemplateKind for template decls found via a using decl.

This is the template version of https://reviews.llvm.org/D114251.

This patch introduces a new template name kind (UsingTemplateName). The
UsingTemplateName stores the found using-shadow decl (and underlying
template can be retrieved from the using-shadow decl). With the new
template name, we can be able to find the using decl that a template
typeloc (e.g. TemplateSpecializationTypeLoc) found its underlying template,
which is useful for tooling use cases (include cleaner etc).

This patch merely focuses on adding the node to the AST.

Next steps:
- support using-decl in qualified template name;
- update the clangd and other tools to use this new node;
- add ast matchers for matching different kinds of template names;

Differential Revision: https://reviews.llvm.org/D123127

show more ...


# d1205bb3 04-Apr-2022 Erich Keane <[email protected]>

Reapply"[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"

AND the followups that fixed builds.

I attempted to get 'cute' and use llvm-cxxfilt to make the test look
nicer, but

Reapply"[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"

AND the followups that fixed builds.

I attempted to get 'cute' and use llvm-cxxfilt to make the test look
nicer, but apparently some of the bots have a version of llvm-cxxfilt
that is not the in-tree one, so it fails to properly demangle the stuff.
I've disabled this "RUN" line.

This reverts commit 50186b63d1807d389f31c515377d94185795ab44.

show more ...


# 50186b63 03-Apr-2022 Nico Weber <[email protected]>

Revert "[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"

This reverts commit 4cf98f973a13c5049322abff43f0dff3c214311b.
The test fails on mac bots, see comments on https://revi

Revert "[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs"

This reverts commit 4cf98f973a13c5049322abff43f0dff3c214311b.
The test fails on mac bots, see comments on https://reviews.llvm.org/D122820

Also reverts follow-ups eb920989865d992093993143ba3c6e71126cbb89 and
861c189d2a5203ba8c8e983e8d2e109c0de153a5.

show more ...


# 4cf98f97 31-Mar-2022 Erich Keane <[email protected]>

[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs

As reported in https://github.com/llvm/llvm-project/issues/54588
and discussed in https://github.com/itanium-cxx-abi/cxx-abi/is

[GH54588]Fix ItaniumMangler for NTTP unnamed unions w/ unnamed structs

As reported in https://github.com/llvm/llvm-project/issues/54588
and discussed in https://github.com/itanium-cxx-abi/cxx-abi/issues/139

We are supposed to do a DFS, pre-order, decl-order search for a name for
the union in this case. Prevoiusly we crashed because the IdentiferInfo
pointer was nullptr, so this makes sure we have a name in the cases
described by the ABI.

I added an llvm-unreachable to cover an unexpected case at the end of
the new function with information/reference to the ABI in case we come
up with some way to get back to here.

Differential Revision: https://reviews.llvm.org/D122820

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3
# ae4dce86 18-Jan-2022 Nathan Sidwell <[email protected]>

[clang][ABI] New C++20 module mangling scheme

Implement a demangleable strong ownership symbol mangling.

* The original module symbol mangling scheme turned out to be
undemangleable.

* The hoped

[clang][ABI] New C++20 module mangling scheme

Implement a demangleable strong ownership symbol mangling.

* The original module symbol mangling scheme turned out to be
undemangleable.

* The hoped-for C++17 compatibility of weak ownership turns out to be
fragile

* C++20 now has better ways of controlling C++17 compatibility

The issue is captured on the ABI list at:
https://github.com/itanium-cxx-abi/cxx-abi/issues/134

GCC implements this new mangling.

The old mangling is unceremoniously dropped. No backwards
compatibility, no deprectated old-mangling flag. It was always
labelled experimental. (Old and new manglings cannot be confused.)

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D122256

show more ...


# 3251ba2d 04-Mar-2022 Yonghong Song <[email protected]>

[Attr] Fix a btf_type_tag AST generation

Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note.

[Attr] Fix a btf_type_tag AST generation

Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note. But this is not enough for btf_type_tag
as the attribute might have the same ModifiedType and EquivType, but
still have different string associated with attribute.

For example, for a data structure like below,
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b;
};
The current ASTContext.getAttributedType() will produce
an AST similar to below:
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b;
};
and this is incorrect.

It is very difficult to use the current AttributedType as it is hard to
get the tag information. To fix the problem, this patch introduced
BTFTagAttributedType which is similar to AttributedType
in many ways but with an additional BTFTypeTagAttr. The tag itself can
be retrieved with BTFTypeTagAttr.
With the new BTFTagAttributed type, the debuginfo code can be greatly
simplified compared to previous TypeLoc based approach.

Differential Revision: https://reviews.llvm.org/D120296

show more ...


# 845f0bb5 09-Mar-2022 Chuanqi Xu <[email protected]>

Revert "[clang][ABI] New C++20 module mangling scheme"

This reverts commit 21e16ab6b8ddaccb70d2344bb35419e214a32ec9.

It looks like it would break builds in mac. See
https://reviews.llvm.org/D118352.


# 21e16ab6 18-Jan-2022 Nathan Sidwell <[email protected]>

[clang][ABI] New C++20 module mangling scheme

The existing module symbol mangling scheme turns out to be
undemangleable. It is also desirable to switch to the
strong-ownership model as the hoped-fo

[clang][ABI] New C++20 module mangling scheme

The existing module symbol mangling scheme turns out to be
undemangleable. It is also desirable to switch to the
strong-ownership model as the hoped-for C++17 compatibility turns out
to be fragile, and we also now have a better way of controlling that.

The issue is captured on the ABI list at:
https://github.com/itanium-cxx-abi/cxx-abi/issues/134

A document describing the issues and new mangling is at:
https://drive.google.com/file/d/1qQjqptzOFT_lfXH8L6-iD9nCRi34wjft/view

This patch is the code-generation part. I have a demangler too, but
that patch is based on some to-be-landed refactoring of the demangler.

The old mangling is unceremoniously dropped. No backwards
compatibility, no deprectated old-mangling flag. It was always
labelled experimental. (Old and new manglings cannot be confused.)

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D118352

show more ...


Revision tags: llvmorg-13.0.1-rc2
# 82e5f951 06-Jan-2022 Peter Collingbourne <[email protected]>

AST: Move __va_list tag back to std conditionally on AArch64.

In post-commit feedback on D104830 Jessica Clarke pointed out that
unconditionally adding __va_list to the std namespace caused namespac

AST: Move __va_list tag back to std conditionally on AArch64.

In post-commit feedback on D104830 Jessica Clarke pointed out that
unconditionally adding __va_list to the std namespace caused namespace
debug info to be emitted in C, which is not only inappropriate but
turned out to confuse the dtrace tool. Therefore, move __va_list back
to std only in C++ so that the correct debug info is generated. We
also considered moving __va_list to the top level unconditionally
but this would contradict the specification and be visible to AST
matchers and such, so make it conditional on the language mode.

To avoid breaking name mangling for __va_list, teach the Itanium
name mangler to always mangle it as if it were in the std namespace
when targeting ARM architectures. This logic is not needed for the
Microsoft name mangler because Microsoft platforms define va_list as
a typedef of char *.

Depends on D116773

Differential Revision: https://reviews.llvm.org/D116774

show more ...


# 18ead233 17-Feb-2022 Peter Collingbourne <[email protected]>

AST: Make getEffectiveDeclContext() a member function of ItaniumMangleContextImpl. NFCI.

In an upcoming change we are going to need to access mangler state
from the getEffectiveDeclContext() functio

AST: Make getEffectiveDeclContext() a member function of ItaniumMangleContextImpl. NFCI.

In an upcoming change we are going to need to access mangler state
from the getEffectiveDeclContext() function. Therefore, make it a
member function of ItaniumMangleContextImpl. Any callers that are
not currently members of ItaniumMangleContextImpl or CXXNameMangler
are made members of one or the other depending on where they are
called from.

Differential Revision: https://reviews.llvm.org/D116773

show more ...


# 082f3288 11-Feb-2022 Nathan Sidwell <[email protected]>

[clang] Itanium mangler constructors

The Itanium mangler constructors use both NSDMI and explicit member
construction for default values. This is confusing.

*) Use NSDMIs wherever possible

*) Use

[clang] Itanium mangler constructors

The Itanium mangler constructors use both NSDMI and explicit member
construction for default values. This is confusing.

*) Use NSDMIs wherever possible

*) Use forwarding ctor for the nesting case with an
llvm::raw_null_ostream (and explicitly set NullOut flag in that ctor).

*) Copy the ModuleSubstitutions. This is a bug with no effect in the
current mangling, but not in the newer mangling.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119550

show more ...


# 02093906 14-Feb-2022 Nathan Sidwell <[email protected]>

[clang][NFC] Remove IgnoreLinkageSpecDecls

The Itanium mangler uses IgnoreLinkageSpecDecls to strip linkage spec
contexts. It doesn't do this consistently, but there is no need for
it to do it at a

[clang][NFC] Remove IgnoreLinkageSpecDecls

The Itanium mangler uses IgnoreLinkageSpecDecls to strip linkage spec
contexts. It doesn't do this consistently, but there is no need for
it to do it at all. getEffectiveDeclContext never returns a linkage
spec, as it either recurses, uses getRedeclContext (which itself
removes the specs), or gets the decl context of non-namespace entities.

This patch removes the function and all calls to it. For safety I add
a couple of asserts to make sure we never get them.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119748

show more ...


# 815446cd 09-Feb-2022 Nathan Sidwell <[email protected]>

[clang][NFC] Standard substitution checking cleanup

In preparing for module mangling changes I noticed some issues with
the way we check for std::basic_string instantiations and friends.

*) there's

[clang][NFC] Standard substitution checking cleanup

In preparing for module mangling changes I noticed some issues with
the way we check for std::basic_string instantiations and friends.

*) there's a single routine for std::basic_{i,o,io}stream but it is
templatized on the length of the name. Really? just use a
StringRef, rather than clone the entire routine just for
'basic_iostream'.

*) We have a helper routine to check for char type, and call it from
several places. But given all the instantiations are of the form
TPL<char, Other<char> ...> we could just check the first arg is char
and the later templated args are instantiating that same type. A
simpler type comparison.

*) Because basic_string has a third allocator parameter, it is open
coded, which I found a little confusing. But otherwise it's exactly
the same pattern as the iostream ones. Just tell that checker about
whether there's an expected allocator argument.[*]

*) We may as well return in each block of mangleStandardSubstitution
once we determine it is not one of the entities of interest -- it
certainly cannot be one of the other kinds of entities.

FWIW this shaves about 500 bytes off the executable.

[*] I suppose we could also have this routine a tri-value, with one to
indicat 'it is this name, but it's not the one you're looking for', to
avoid later calls trying different names?

Reviewd By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119333

show more ...


# 493c8564 20-Jan-2022 Nathan Sidwell <[email protected]>

[clang][NFC] Small mangler cleanups

In working on a module mangling problem I noticed a few cleanups to the mangler.

1) Use 'if (auto x = ...' idiom in a couple of places.

2) I noticed both 'isFil

[clang][NFC] Small mangler cleanups

In working on a module mangling problem I noticed a few cleanups to the mangler.

1) Use 'if (auto x = ...' idiom in a couple of places.

2) I noticed both 'isFileContext' and 'isNamespace || isTranslationUnit'
synonyms. Let's use the former.

3) The control flow in the seqId mangling was misordered. Let's channel Count
von Count. Also fix the inconsistent bracing.

Differential Revision: https://reviews.llvm.org/D117799

show more ...


# af27466c 20-Dec-2021 Sam McCall <[email protected]>

Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a.
Fixed a bad assertion, the target of a UsingShadowDecl must not

Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a.
Fixed a bad assertion, the target of a UsingShadowDecl must not have
*local* qualifiers, but it can be a typedef whose underlying type is qualified.

show more ...


# cc56c66f 20-Dec-2021 Sam McCall <[email protected]>

Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.

Breaks sanitizer tests, at least on windows:
https://lab.llvm.

Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"

This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.

Breaks sanitizer tests, at least on windows:
https://lab.llvm.org/buildbot/#/builders/127/builds/21592/steps/4/logs/stdio

show more ...


12345678910>>...21