It is not needed after LLVM r327734. Now it will be easier to copy-paste
IR symbol names from Clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@327738 91177308-0d34-0410-b5e6-96231b3b80d8
The tests that failed on a windows host have been fixed.
Original message:
Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@325940 91177308-0d34-0410-b5e6-96231b3b80d8
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@325915 91177308-0d34-0410-b5e6-96231b3b80d8
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313729 91177308-0d34-0410-b5e6-96231b3b80d8
This implements support for MS-specific __unaligned qualifier in functions and
makes the following test case both compile and mangle correctly:
struct S {
void f() __unaligned;
};
void S::f() __unaligned {
}
Differential Revision: http://reviews.llvm.org/D20437
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270834 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367 and PR27666.
Differential Revision: http://reviews.llvm.org/D20103
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269220 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements __unaligned as a type qualifier; before that, it was
modeled as an attribute. Proper mangling of __unaligned is implemented as well.
Some OpenCL code/tests are tangenially affected, as they relied on existing
number and sizes of type qualifiers.
Differential Revision: http://reviews.llvm.org/D18596
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266415 91177308-0d34-0410-b5e6-96231b3b80d8
We might get into bad situations where we try to embed the signature of
an inner lambda into an outer lambda which cannot work: the inner lambda
wants to embed the name of the outer lambda!
Instead, omit the return type for lambdas.
This fixes PR26105.
N.B. While we are here, make lambdas nested within functions use an
artificial scope so that they can get demangled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258003 91177308-0d34-0410-b5e6-96231b3b80d8
We believed that internal linkage variables at global scope which are
not variable template specializations did not have to be mangled.
However, static anonymous unions have no identifier and therefore must
be mangled.
This fixes PR18204.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250997 91177308-0d34-0410-b5e6-96231b3b80d8
TagDecls (structs, enums, etc.) may have the same name for linkage
purposes of one another; to disambiguate, we add a number to the mangled
named. However, we didn't do this if the TagDecl has a pseudo-name for
linkage purposes (it was defined alongside a DeclaratorDecl or a
TypeNameDecl).
This fixes PR24651.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246659 91177308-0d34-0410-b5e6-96231b3b80d8
A class without a name for linkage purposes gets a name along the lines
of <unnamed-type-foo> where foo is either the name of a declarator which
defined it (like a variable or field) or a
typedef-name (like a typedef or alias-declaration).
We handled the declarator case correctly but it would fall down during
template instantiation if the declarator didn't share the tag's type.
We failed to handle the typedef-name case at all.
Instead, keep track of the association between the two and keep it up to
date in the face of template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246469 91177308-0d34-0410-b5e6-96231b3b80d8
consider C++ that looks like:
inline int &f(bool b) {
if (b) {
static int i;
return i;
}
static int i;
return i;
}
Both 'i' variables must have distinct (and stable) names for linkage
purposes. The MSVC 2013 ABI would number the variables using a count of
the number of scopes that have been created. However, the final 'i'
returns to a scope that has already been created leading to a mangling
collision.
MSVC 2015 fixes this by giving the second 'i' the name it would have if
it were declared before the 'if'. However, this results in ABI breakage
because the mangled name, in cases where there was no ambiguity, would
now be different.
We implement the new behavior and only enable it if we are targeting the
MSVC 2015 ABI, otherwise the old behavior will be used.
This fixes PR18131.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232766 91177308-0d34-0410-b5e6-96231b3b80d8
We used to support the 2013 mangling and changed it to the more
reasonable 2015 mangling. Let's make the mangling conditional on what
version of MSVC is targeted.
This fixes PR21888.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232609 91177308-0d34-0410-b5e6-96231b3b80d8
These mangling make clang more compatible with MSVC 2015.
Correctly mangling char16_t and char32_t will take a little more work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222515 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC "14" CTP 3 has fixed it's mangling for alias templates when used as
template-template arguments; update clang to be compatible with this
mangling.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215972 91177308-0d34-0410-b5e6-96231b3b80d8
C++11 allows this qualifiers to exist on function types when used in
template arguments. Previously, I believed it wasn't possible because
MSVC rejected declarations like: S<int () const &> s;
However, it turns out MSVC properly allows them in using declarations;
updated clang to be compatible with this mangling.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215464 91177308-0d34-0410-b5e6-96231b3b80d8
It is possible for lambdas to get the same mangling number because they
may exist in different mangling contexts. To handle this correctly,
mangle the context into the name as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214947 91177308-0d34-0410-b5e6-96231b3b80d8
The MS mangling scheme apparently has separate manglings for type and
non-type parameter packs when they are empty. Match template arguments
with parameters during mangling; check the parameter to see if it was
destined to hold type-ish things or nontype-ish things.
Differential Revision: http://reviews.llvm.org/D4792
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214932 91177308-0d34-0410-b5e6-96231b3b80d8
A templated using declaration may be used as a template-template
argument.
Unfortunately, the VS "14" chooses '?' as the sole marker for the
argument. This is problematic because it presupposes the possibility of
using more than one template-aliases as arguments to the same template.
This fixes PR20047.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214290 91177308-0d34-0410-b5e6-96231b3b80d8
Straightforward implementation of UDLs, it's compatible with VS "14".
This nearly completes our implementation of C++ name mangling for the
MS-ABI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210197 91177308-0d34-0410-b5e6-96231b3b80d8
Use a scheme inspired by the Itanium ABI to properly implement the
mangling of lambdas.
N.B. The incredibly astute observer will notice that we do not generate
external names that are identical, or even compatible with, MSVC.
This is fine because they don't generate names that they can use across
translation units. Technically, we can generate any name we'd like so
long as that name wouldn't conflict with any other and would be stable
across translation units.
This fixes PR15512.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202962 91177308-0d34-0410-b5e6-96231b3b80d8
The MSVC C++ ABI always uses the deduced type in place of auto when
generating external names for variables.
N.B. MSVC doesn't support C++1y's 'operator auto' and this patch will
not give us said functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199764 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199250 91177308-0d34-0410-b5e6-96231b3b80d8
Hans Wennborg