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
Xiuli Pan