This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367.
Differential Revision: http://reviews.llvm.org/D19654
llvm-svn: 268727
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
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
llvm-svn: 266415
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header".
This fixes the modules build.
Differential revision: http://reviews.llvm.org/D18954
Reviewers: Richard Smith, Vassil Vassilev.
llvm-svn: 266180
I. Current implementation of images is not conformant to spec in the following points:
1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine:
void write_image(write_only image2d_t img);
kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code
which is disallowed according to s6.13.14.
2. It discards access qualifier on generated code, which leads to generated code for the above example:
call void @write_image(%opencl.image2d_t* %img);
In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images.
Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently.
3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names.
4. Default access qualifier read_only is to be added if not provided explicitly.
II. This patch corrects the above points as follows:
1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type.
2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers).
3. Improves testing of images in Clang.
Author: Anastasia Stulova
Reviewers: bader, mgrang.
Subscribers: pxli168, pekka.jaaskelainen, yaxunl.
Differential Revision: http://reviews.llvm.org/D17821
llvm-svn: 265783
I broke this back in r264529 because I forgot to serialize the UuidAttr
member. Fix this by replacing the UuidAttr with a StringRef which is
properly serialized and deserialized.
llvm-svn: 264562
Keep a pointer to the UuidAttr that the CXXUuidofExpr corresponds to.
This makes translating from __uuidof to the underlying constant a lot
more straightforward.
llvm-svn: 264529
Really long symbols are hashed using MD5 and prefixed/suffixed with the
usual sigils. There is an additional reason beyond the usual
compatibility with MSVC, it is important to keep COFF symbols shorter
than 0xFFFF because the CodeView debugging format has a maximum
symbol/record size of 0xFFFF.
There are some quirks worth noting:
- Some mangled names reference other entities which are mangled
separately. A quick example:
int I;
template <int *> struct S {};
S<I> s;
In this case, the mangling for 's' doesn't depend directly on the
mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed
one, the hash for 's' applied to the fully realized mangled name. In
other words, the mangled name for 's' will not depend on the MD5 of the
mangled name for 'I'.
- Some mangled names, like the venerable CatchableType, embed the MD5
verbatim.
- Finally, the complete object locator is handled as a special case.
A complete object locators are mangled exactly like a VFTable except for
a small deviation in the prefix sigils. However, complete object
locators for hashed vftables result in a complete object locator whose
name is identical to the vftable except for an additional suffix.
llvm-svn: 262818
Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are defined as
#pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )]
These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The
combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will
denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting
combined value after executing the combiner.
As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause
will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier
omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced.
Differential Revision: http://reviews.llvm.org/D11182
llvm-svn: 262582
This reverts commit r260449.
We would supress our emission of vftable definitions if we thought
another translation unit would provide the definition because we saw an
explicit instantiation declaration. This is not the case with
dllimport, we want to synthesize a definition of the vftable regardless.
This fixes PR26569.
llvm-svn: 260548
Referencing a dllimported vtable is impossible in a constexpr
constructor. It would be friendlier to C++ programmers if we
synthesized a copy of the vftable which referenced imported virtual
functions. This would let us initialize the object in a way which
preserves both the intent to import functionality from another DLL while
also making constexpr work.
Differential Revision: http://reviews.llvm.org/D17061
llvm-svn: 260388
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.
llvm-svn: 258003
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
llvm-svn: 257254
Only function template specializations are exempt from being added to
the NameBackReferences. Redundant variable template specializations
should be appropriately substituted.
llvm-svn: 256623
We didn't add the artificial pass_object_size arguments to the
backreference map which bloated the size of manglings which involved
pass_object_size with duplicate types.
This lets us go from:
?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z
to:
?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z
llvm-svn: 256622
MSVC doesn't implement a mangling for C99's _Complex so we must invent
our own.
For now, treating it like a class type called _Complex in the __clang
namespace.
This means that 'void f(__Complex int))'
will demangle as: 'void f(struct __clang::_Complex<int>)'
llvm-svn: 256583
MSVC doesn't implement a mangling for C11's _Atomic so we must invent
our own.
For now, treating it like a class type called _Atomic in the __clang
namespace.
This means that 'void f(__Atomic(int))'
will demangle as: 'void f(struct __clang::_Atomic<int>)'
llvm-svn: 256557
We used to produce a type which demangled to:
union __clang_vec8_F
That 'F' is the mangling for 'short' but it is present in the mangled
name in an inappropriate place, leading to it not getting demangled.
Instead, create a synthetic class type in a synthetic namespace called
__clang. With this, it now demangles to:
union __clang::__vector<short,8>
llvm-svn: 256556
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
llvm-svn: 254554
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
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.
llvm-svn: 250997
This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.
Differential Revision: http://reviews.llvm.org/D11857
llvm-svn: 247238
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.
llvm-svn: 246659
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.
llvm-svn: 246469
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.
Thanks to David Blaikie for reviewing.
llvm-svn: 244928
Function types without prototypes can arise when mangling a function type
within an overloadable function in C. We mangle these as the absence of
any parameter types (not even an empty parameter list).
Differential Revision: http://reviews.llvm.org/D11848
llvm-svn: 244374
It turns out that nullptr pointers to data members act differently in
function templates vs class templates. Class templates use a variable
width representation proportional to the number of fields needed to
materialize it. Function templates always use a single '0' template
parameter. However, using '0' all the time is problematic if the class
uses single or multiple inheritance. In those cases, use -1.
llvm-svn: 241251
Virtual inheritance member pointers are always relative to the vbindex,
even when the member pointer doesn't point into a virtual base. This is
corrected by adjusting the non-virtual offset backwards from the vbptr
back to the top of the most derived class. While we performed this
adjustment when manifesting member pointers as constants or when
performing conversions, we didn't perform the adjustment when mangling
them.
llvm-svn: 240453
Member pointers in the MS ABI are made complicated due to the following:
- Virtual methods in the most derived class (MDC) might live in a
vftable in a virtual base.
- There are four different representations of member pointer: single
inheritance, multiple inheritance, virtual inheritance and the "most
general" representation.
- Bases might have a *more* general representation than classes which
derived from them, a most surprising result.
We believed that we could treat all member pointers as-if they were a
degenerate case of the multiple inheritance model. This fell apart once
we realized that implementing standard member pointers using this ABI
requires referencing members with a non-zero vbindex.
On a bright note, all but the virtual inheritance model operate rather
similarly. The virtual inheritance member pointer representation
awkwardly requires a virtual base adjustment in order to refer to
entities in the MDC.
However, the first virtual base might be quite far from the start of the
virtual base. This means that we must add a negative non-virtual
displacement.
However, things get even more complicated. The most general
representation interprets vbindex zero differently from the virtual
inheritance model: it doesn't reference the vbtable at all.
It turns out that this complexity can increase for quite some time:
consider a derived to base conversion from the most general model to the
multiple inheritance model...
To manage this complexity we introduce a concept of "normalized" member
pointer which allows us to treat all three models as the most general
model. Then we try to figure out how to map this generalized member
pointer onto the destination member pointer model. I've done my best to
furnish the code with comments explaining why each adjustment is
performed.
This fixes PR23878.
llvm-svn: 240384
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
Clang's control flow integrity implementation works by conceptually attaching
"tags" (in the form of bitset entries) to each virtual table, identifying
the names of the classes that the virtual table is compatible with. Under
the Itanium ABI, it is simple to assign tags to virtual tables; they are
simply the address points, which are available via VTableLayout. Because any
overridden methods receive an entry in the derived class's virtual table,
a check for an overridden method call can always be done by checking the
tag of whichever derived class overrode the method call.
The Microsoft ABI is a little different, as it does not directly use address
points, and overrides in a derived class do not cause new virtual table entries
to be added to the derived class; instead, the slot in the base class is
reused, and the compiler needs to adjust the this pointer at the call site
to (generally) the base class that initially defined the method. After the
this pointer has been adjusted, we cannot check for the derived class's tag,
as the virtual table may not be compatible with the derived class. So we
need to determine which base class we have been adjusted to.
Specifically, at each call site, we use ASTRecordLayout to identify the most
derived class whose virtual table is laid out at the "this" pointer offset
we are using to make the call, and check the virtual table for that tag.
Because address point information is unavailable, we "reconstruct" it as
follows: any virtual tables we create for a non-derived class receive a tag
for that class, and virtual tables for a base class inside a derived class
receive a tag for the base class, together with tags for any derived classes
which are laid out at the same position as the derived class (and therefore
have compatible virtual tables).
Differential Revision: http://reviews.llvm.org/D10520
llvm-svn: 240117
We probably shouldn't say that all appropriately sized vector types are
intel vector types (i.e. __m128, etc.) as they don't exist for all
architectures. While this is largely academic, it'd save some debugging
if we supported such a platform.
llvm-svn: 238731
It turns out that there is a mangling for 'extern "C"', it's only used
by MSVC in /clr mode. Co-opt this mangling so that extern "C" functions
marked overloadable get demangled nicely.
llvm-svn: 237548
The MSVC 2015 ABI utilizes a rather straightforward adaptation of the
algorithm found in the appendix of N2382. While we are here, implement
support for emitting cleanups if an exception is thrown while we are
intitializing a static local variable.
llvm-svn: 236697
Using GetNumBytesInBuffer() assumes that the stream was not flushed between
the GetNumBytesInBuffer() calls, which may happen to be true or not,
depending on stream policy. tell() always reports the correct stream location.
Do note there are only two more uses of GetNumBytesInBuffer() in LLVM+clang, in
lib/MC/MCAsmStreamer.cpp and lib/Target/R600/InstPrinter/AMDGPUInstPrinter.cpp.
The former may be replacable by tell (needs testing) but while the later can
not be immediatly replaced by tell() as it uses the absolute value of
GetNumBytesInBuffer() rather than the real stream position. Both uses seems
to depend upon flush policy and thus may not work correctly depending upon the
stream behaviour.
Going forward, GetNumBytesInBuffer() should probably be protected, non-accessible
to raw_ostream clients.
llvm-svn: 236389
Type backreferences for arguments use the DecayedType's original type.
Because of this, arguments with the same canonical type with the same
mangling would not backreference each other if one was a
ConstantArrayType while the other was an IncompleteArrayType. Solve
this by canonicalizing the ConstantArrayType to a suitable
IncompleteArrayType.
This fixes PR23325.
llvm-svn: 235572
Even though these symbols are in a comdat group, the Microsoft linker
really wants them to have internal linkage.
I'm planning to tweak the mangling in a follow-up change. This is a
straight revert with a 1-line fix.
llvm-svn: 234613
WinEHPrepare was going to have to pattern match the control flow merge
and split that the old lowering used, and that wasn't really feasible.
Now we can teach WinEHPrepare to pattern match this, which is much
simpler:
%fp = call i8* @llvm.frameaddress(i32 0)
call void @func(iN [01], i8* %fp)
This prototype happens to match the prototype used by the Win64 SEH
personality function, so this is really simple.
llvm-svn: 234532
Utilizing IMAGEREL relocations for synthetic IR constructs isn't
valuable, just clutter. While we are here, simplify HandlerType names
by making the numeric value for the 'adjective' part of the mangled name
instead of appending '.const', etc. The old scheme made for very long
global names and leads to wordy things like '.std_bad_alloc'
llvm-svn: 233503
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.
llvm-svn: 232609
The HandlerMap describes, to the runtime, what sort of catches surround
the try. In principle, this structure has to be emitted by the backend
because only it knows the layout of the stack (the runtime needs to know
where on the stack the destination of a copy lives, etc.) but there is
some C++ specific information that the backend can't reason about.
Stick this information in special LLVM globals with the relevant
"const", "volatile", "reference" info mangled into the name.
llvm-svn: 232538
Virtual member pointers are implemented using a thunk. We assumed that
the calling convention for this thunk was always __thiscall for 32-bit
targets and __cdecl for 64-bit targets. However, this is not the case.
Mangle in whichever calling convention is appropriate for this member
function thunk.
llvm-svn: 232254
The MS ABI utilizes a compiler generated function called the "vector
constructor iterator" to construct arrays of objects with
non-trivial constructors/destructors. For this to work, the constructor
must follow a specific calling convention. A thunk must be created if
the default constructor has default arguments, is variadic or is
otherwise incompatible. This thunk is called the default constructor
closure.
N.B. Default constructor closures are only generated if the default
constructor is exported because clang itself does not utilize vector
constructor iterators. Failing to export the default constructor
closure will result in link/load failure if a translation unit compiled
with MSVC is on the import side.
Differential Revision: http://reviews.llvm.org/D8331
llvm-svn: 232229
This adds support for copy-constructor closures. These are generated
when the C++ runtime has to call a copy-constructor with a particular
calling convention or with default arguments substituted in to the call.
Because the runtime has no mechanism to call the function with a
different calling convention or know-how to evaluate the default
arguments at run-time, we create a thunk which will do all the
appropriate work and package it in a way the runtime can use.
Differential Revision: http://reviews.llvm.org/D8225
llvm-svn: 231952
Because the catchable type has a reference to its name, mangle the
location to ensure that two catchable types with different locations are
distinct.
llvm-svn: 231819
Find all unambiguous public classes of the exception object's class type
and reference all of their copy constructors. Yes, this is not
conforming but it is necessary in order to implement their ABI. This is
because the copy constructor is actually referenced by the metadata
describing which catch handlers are eligible to handle the exception
object.
N.B. This doesn't yet handle the copy constructor closure case yet,
that work is ongoing.
Differential Revision: http://reviews.llvm.org/D8101
llvm-svn: 231499
Throwing a C++ exception, under the MS ABI, is implemented using three
components:
- ThrowInfo structure which contains information like CV qualifiers,
what destructor to call and a pointer to the CatchableTypeArray.
- In a significant departure from the Itanium ABI, copying by-value
occurs in the runtime and not at the catch site. This means we need
to enumerate all possible types that this exception could be caught as
and encode the necessary information to convert from the exception
object's type to the catch handler's type. This includes complicated
derived to base conversions and the execution of copy-constructors.
N.B. This implementation doesn't support the execution of a
copy-constructor from within the runtime for now. Adding support for
that functionality is quite difficult due to things like default
argument expressions which may evaluate arbitrary code hiding in the
copy-constructor's parameters.
Differential Revision: http://reviews.llvm.org/D8066
llvm-svn: 231328
This patch introduces the -fsanitize=cfi-vptr flag, which enables a control
flow integrity scheme that checks that virtual calls take place using a vptr of
the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst
file.
It also introduces the -fsanitize=cfi flag, which is currently a synonym for
-fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented
in Clang.
Differential Revision: http://reviews.llvm.org/D7424
llvm-svn: 230055
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad
normal:
store i32 %rr, i32* %r
ret i1 1
lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume
eh.except:
ret i1 false
eh.resume:
resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
We previously had support for char and wchar_t string literals. VS 2015
added support for char16_t and char32_t.
String literals must be mangled in the MS ABI in order for them to be
deduplicated across translation units: their linker has no notion of
mergeable section. Instead, they use the mangled name to make a COMDAT
for the string literal; the COMDAT will merge with other COMDATs in
other object files.
This allows strings in object files generated by clang to get merged
with strings in object files generated by MSVC.
llvm-svn: 222564
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
This changes the scope discriminator's behavior to start at '1' instead
of '0'. Symbol table diffing, for ABI compatibility testing, kept
finding these as false positives.
llvm-svn: 219075
This patch replaces the back reference StringMap from the MS mangler
with a SmallVector of strings. My previous patches reduced the number of
hashes involved in back reference lookups, this one removes them
completely. The back reference map contains at most 10 entries, which
are likely to be of varying sizes and different initial subsequences,
and which can easily became huge (due to templates and namespaces).
The solution presented is the simplest possible one. Nevertheless, it's
enough to reduce compilation times for a particular test case from 11.1s
to 9s, versus 8.58s for the Itanium ABI. Possible further improvements
include using a sorted vector (carefully to not introduce an extra
comparison), storing the string contents in a common arena, and/or keep
the string storage in the context for reuse.
Patch by Agustín Bergé.
llvm-svn: 218461
There are situations when clang knows that the C1 and C2 constructors
or the D1 and D2 destructors are identical. We already optimize some
of these cases, but cannot optimize it when the GlobalValue is
weak_odr.
The problem with weak_odr is that an old TU seeing the same code will
have a C1 and a C2 comdat with the corresponding symbols. We cannot
suddenly start putting the C2 symbol in the C1 comdat as we cannot
guarantee that the linker will not pick a .o with only C1 in it.
The solution implemented by GCC is to expand the ABI to have a comdat
whose name uses a C5/D5 suffix and always has both symbols. That is
what this patch implements.
llvm-svn: 217874
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.
llvm-svn: 215972
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.
llvm-svn: 215464
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.
llvm-svn: 214947
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
llvm-svn: 214932
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.
llvm-svn: 214290
Avoid a second key lookup when the back reference key is going to be
inserted in the StringMap. The string lookups in the msmangler are the
main responsible for the huge overhead when compared to the itanium
mangler. This patch makes a small but noticeable improvement.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4130
Patch by Agustín Bergé!
llvm-svn: 211813
VarDecl provides a method getSourceRange(), which provides a more
robust way of getting the SourceRange since the TypeSourceInfo can
be null in certain cases.
Reviewed by: majnemer
Differential Revision: http://reviews.llvm.org/D4281
llvm-svn: 211667
r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it
did not believe that there is a distinction between class templates and
function templates.
Sadly, there is. Function templates should behave in a compatible
manner with MSVC.
llvm-svn: 210642
Summary:
Previously, we would mangle nullptr pointer-to-member-functions in class
templates with a mangling we invented because contemporary versions of
MSVC would crash when trying to compile such code.
However, VS "14" can successfully compile these sorts of template
instantiations. This commit updates our mangling to be compatible with
theirs.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4059
llvm-svn: 210637
Use mangled template instantiation name as key for back references.
Templates have their own context for back references, so their mangling
is always the same regardless of context. This avoids mangling template
instantiations twice.
Patch by Agustín Bergé!
llvm-svn: 210416
Straightforward implementation of UDLs, it's compatible with VS "14".
This nearly completes our implementation of C++ name mangling for the
MS-ABI.
llvm-svn: 210197
Enables the emission of MS-compatible RTTI data structures for use with
typeid, dynamic_cast and exceptions. Does not implement dynamic_cast
or exceptions. As an artiface, typeid works in some cases but proper
support an testing will coming in a subsequent patch.
majnemer has fuzzed the results. Test cases included.
Differential Revision: http://reviews.llvm.org/D3833
llvm-svn: 209523
Implement what we currently believe is the mangling scheme for RTTI
data. Tests will be added in a later commit which actually generate
RTTI data.
llvm-svn: 208661
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
llvm-svn: 207776
This can actually be non-zero if you override a function from a virtual
base and you have forced the most_general pointer to member
representation.
llvm-svn: 205727
The MS ABI forces us into catch-22 when it comes to functions which
return types which are local:
- A function is mangled with it's return type.
- A type is mangled with it's surrounding context.
Avoid this by mangling auto and decltype(autp) directly into the
function's return type. Using this mangling has the double advantage of
being compatible with the C++ standard without crashing the compiler.
N.B. For the curious, the MSVC mangling leads to collisions amongst
template functions and either crashes when faced with local types or is
otherwise incapable of returning them.
llvm-svn: 205282
It turns out that the ranges where the '?' <letter> manglings occur are
identical to the ranges of ASCII characters OR'd with 0x80.
Thanks to Richard Smith for the insight!
No functional change.
llvm-svn: 205270
The delta between '\xe1' and '\xc1' is equivalent to the one between 'a'
and 'A'. This allows us to reuse the computation between '\xe1' and
'\xfa' for the '\xc1' to '\xda' case.
No functionality change.
llvm-svn: 205128
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
llvm-svn: 204675
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
llvm-svn: 204586
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
llvm-svn: 204562
If a guard variable will be created for an entity at global scope,
then we cannot rely on the scope depth to disambiguate names for us.
Instead, mangle the entire variable into the guard to ensure it's uniqueness.
llvm-svn: 203151
Initializers and finalizers for static data members have the variable's
access-specifier, storage-class, type and CV-qualifiers mangled in.
llvm-svn: 203145
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.
llvm-svn: 202962
Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics. Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise. For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.
There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
never encountered scope is entered. There are cases where this will
cause ambiguity amongst declarations that have the same name where one
was introduced in a deep scope while the other was introduced right
after in the previous lexical scope.
- It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}}
will make the mangling of "foo" larger than it need be because the
scope counter has been incremented many times.
Because of these problems, and practical implementation concerns. We
choose not to implement this scheme if the local static or local type
isn't visible. The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.
Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2953
llvm-svn: 202951
We wouldn't recognize variable templates as being templates leading us
to leave the template arguments off of the mangled name. This would
allow two unrelated templates to map to the same mangled name.
N.B. While MSVC doesn't support variable templates as of this date,
this mangling is the most likely thing they will choose to use. Their
demangler can successfully demangle our manglings with the template
arguments shown.
llvm-svn: 202789
Extended qualifiers can appear in many places, refactor the code so it's
more reusable. Add tests in areas where we've increased compatibility.
llvm-svn: 201574
Pointer types in the MSVC ABI are a bit awkward, the width of the
pointer is considered a kind of CVR qualifier.
Restrict is handled similarly to const and volatile but is mangled after
the pointer width qualifier.
This fixes PR18880.
llvm-svn: 201569
Properly support fields that come from anonymous unions and structs
when used as template arguments for pointer to data member params.
llvm-svn: 200921
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
llvm-svn: 200920
Function references always use $1? like function pointers and never $E?
like var decl references. Static methods are mangled like function
pointers.
llvm-svn: 200869
Member pointers are mangled as they would be represented at runtime.
They can be a single integer literal, single decl, or a tuple with some
more numbers tossed in. With Clang today, most of those numbers will be
zero because we reject pointers to members of virtual bases.
This change required moving VTableContextBase ownership from
CodeGenVTables to ASTContext, because mangling now depends on vtable
layout.
I also hoisted the inheritance model helpers up to be inline static
methods of MSInheritanceAttr. This makes the AST code that deals with
member pointers much more readable.
MSVC doesn't appear to have stable manglings of null member pointers:
- Null data memptrs in function templates have a mangling collision with
the first field of a non-polymorphic single inheritance class.
- The mangling of null data memptrs changes if you add casts.
- Large null function memptrs in class templates crash MSVC.
Clang uses the class template mangling for null data memptrs and the
function template mangling for null function memptrs to deal with this.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2695
llvm-svn: 200857
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
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.
llvm-svn: 199764
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
This reverts commit r197184.
Richard Smith brings up some good points, a proper implementation will
require us to mangle unnameable entities compatibly with MSVC.
llvm-svn: 197192
Testing has revealed that large integral constants (i.e. > INT64_MAX)
are always mangled as-if they are negative, even in places where it
would not make sense for them to be negative (like non-type template
parameters of type unsigned long long).
To address this, we change the way we model number mangling: always
mangle as-if our number is an int64_t. This should result in correct
results when we have large unsigned numbers.
N.B. Bizarrely, things that are 32-bit displacements like vbptr offsets
are mangled as-if they are unsigned 32-bit numbers. This is a pretty
egregious waste of space, it would be a 4x savings if we could mangle it
like a signed 32-bit number. Instead, we explicitly cast these
displacements to uint32_t and let the mangler proceed.
llvm-svn: 196771
While testing our ability to mangle large constants (PR18175), I
incidentally discovered that we did not properly mangle enums correctly.
Previously, we would append the width of the enum in bytes after the
type-tag differentiator.
This would mean "enum : short" would be mangled as 'W2' while "enum :
char" would be mangled as 'W1'. Upon testing this with several versions
of MSVC, I found that this did not match their behavior: they always use
'W4'.
N.B. Quick testing uncovered that undname allows different numbers to
follow the 'W' in the following way:
'W0' -> "enum char"
'W1' -> "enum unsigned char"
'W2' -> "enum short"
'W3' -> "enum unsigned short"
'W4' -> "enum"
'W5' -> "enum unsigned int"
'W6' -> "enum long"
'W7' -> "enum unsigned long"
However this scheme appears abandoned, I cannot get MSVC to trigger it.
Furthermore, it's incomplete: it doesn't handle "bool" or "long long".
llvm-svn: 196752
It wasn't possible for an anonymous type to show up inside of function arguments.
However, decltype (which MSVC added support for in 2010) makes this
possible. Further, backrefs to these anonymous types can now be formed.
This fixes PR18022.
N.B. We do not, and very likely _will not_, support MSVC's bug where
subsequent typedefs of anonymous types leak into the linkage name; this
is a gross violation of the ABI. A warning should be introduced to
inform our users of this particular shortcoming.
llvm-svn: 195669
Summary:
RTTI is not yet implemented for the Microsoft C++ ABI and isn't expected
soon. We could easily add the mangling, but the error is what prevents
us from silently miscompiling code that expects RTTI.
Instead, add a new mangleTypeName entry point that simply forwards to
mangleName or mangleType to produce a string that isn't part of the ABI.
Itanium can continue to use RTTI names to avoid unecessary test
breakage.
This also seems like the right design. The fact that TBAA names happen
to be RTTI names is now an implementation detail of the mangler, rather
than part of TBAA.
Differential Revision: http://llvm-reviews.chandlerc.com/D2153
llvm-svn: 195168
Instead of storing the vtable offset directly in the function pointer and
doing a branch to check for virtualness at each call site, the MS ABI
generates a thunk for calling the function at a specific vtable offset,
and puts that in the function pointer.
This patch adds support for emitting such thunks. However, it doesn't support
pointers to virtual member functions that are variadic, have an incomplete
aggregate return type or parameter, or are overriding a function in a virtual
base class.
Differential Revision: http://llvm-reviews.chandlerc.com/D2104
llvm-svn: 194827
This removes the dependency on the llvm mangler doing it for us. In isolation,
the benefit is that the testing of what mangling is applied is all in one place:
(C, C++) X (Itanium, Microsoft) are all handled by clang.
This also gives me hope that in the future the llvm mangler (and llvm-ar) will
not depend on TargetMachine.
llvm-svn: 192762
Summary:
Operator new, new[], delete, and delete[] are all implicitly static when
declared inside a record. CXXMethodDecl already knows this, but we need
to account for that before we pick the calling convention for the
function type.
Fixes PR17371.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1761
llvm-svn: 192150
Summary:
When selecting a mangling for an anonymous tag type:
- We should first try it's typedef'd name.
- If that doesn't work, we should mangle in the name of the declarator
that specified it as a declaration specifier.
- If that doesn't work, fall back to a static mangling of
<unnamed-type>.
This should make our anonymous type mangling compatible.
This partially fixes PR16994; we would need to have an implementation of
scope numbering to get it right (a separate issue).
Reviewers: rnk, rsmith, rjmccall, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1540
llvm-svn: 190892
Summary:
This fixes several issues with the original implementation:
- Win32 entry points cannot be in namespaces
- A Win32 entry point cannot be a function template, diagnose if we it.
- Win32 entry points cannot be overloaded.
- Win32 entry points implicitly return, similar to main.
Reviewers: rnk, rsmith, whunt, timurrrr
Reviewed By: rnk
CC: cfe-commits, nrieck
Differential Revision: http://llvm-reviews.chandlerc.com/D1683
llvm-svn: 190818
Summary:
Functions named "main", "wmain", "WinMain", "wWinMain", and "DllMain"
are never mangled regardless of linkage, even when compiling for kernel
mode.
Depends on D1655
Reviewers: timurrrr, pcc, rnk, whunt
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1670
llvm-svn: 190675
Summary:
This is a first step to getting extern "C" working properly inside
clang. There are a number of quirks but mangling declarations inside
such a function are a good first step.
Reviewers: timurrrr, pcc, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1655
llvm-svn: 190671
Summary:
More accurately characterize the nature of array parameters. Doing this
removes false back-reference opportunities. Remove some hacks now that
we characterize these better.
Reviewers: rnk, timurrrr, whunt, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1626
llvm-svn: 190488
Static locals requiring initialization are not thread safe on Windows.
Unfortunately, it's possible to create static locals that are actually
externally visible with inline functions and templates. As a result, we
have to implement an initialization guard scheme that is compatible with
TUs built by MSVC, which makes thread safety prohibitively difficult.
MSVC's scheme is that every function that requires a guard gets an i32
bitfield. Each static local is assigned a bit that indicates if it has
been initialized, up to 32 bits, at which point a new bitfield is
created. MSVC rejects inline functions with more than 32 static locals,
and the externally visible mangling (?_B) only allows for one guard
variable per function.
On Eli's recommendation, I used MangleNumberingContext to track which
bit each static corresponds to.
Implements PR16888.
Reviewers: rjmccall, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1416
llvm-svn: 190427
Summary:
Makes functions with implicit calling convention compatible with
function types with a matching explicit calling convention. This fixes
things like calls to qsort(), which has an explicit __cdecl attribute on
the comparator in Windows headers.
Clang will now infer the calling convention from the declarator. There
are two cases when the CC must be adjusted during redeclaration:
1. When defining a non-inline static method.
2. When redeclaring a function with an implicit or mismatched
convention.
Fixes PR13457, and allows clang to compile CommandLine.cpp for the
Microsoft C++ ABI.
Excellent test cases provided by Alexander Zinenko!
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1231
llvm-svn: 189412
Summary:
HandleTopLevelDecl on a templated function leads us to try and mangle
it.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1412
llvm-svn: 188536
Summary:
There were several things going wrong:
- We mangled in useless qualifiers like "volatile void" return types.
- We didn't propagate 64-bit pointer markers sufficiently.
- We mangled qualifiers belonging to the pointee incorrectly.
This fixes PR16844 and PR16848.
Reviewers: rnk, whunt
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1353
llvm-svn: 188450
Summary:
It seems that __uuidof introduces a global extern "C" declaration of
type __s_GUID. However, our implementation of __uuidof does not provide
such a declaration and thus must open-code the mangling for __uuidof in
template parameters.
This allows us to codegen scoped COM pointers and other such things.
This fixes PR16836.
Depends on D1356.
Reviewers: rnk, cdavis5x, rsmith
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1357
llvm-svn: 188252
We mangled them like:
L___uuid_12345678-1234-1234-1234-123456789abc
We should've mangled them like:
__GUID_12345678_1234_1234_1234_123456789abc
Furthermore, they are external symbols.
llvm-svn: 188053
There were three things missing from the original implementation:
- We would omit the 'E' qualifier for members int 64-bit mode.
- We would not exmaine the qualifiers in 'IsMember' mode.
- We didn't generate the correct backref to the base class.
llvm-svn: 187753
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
Nico Weber