The mangling used to contain the MD5 name of both the RTTI type
descriptor and the name of the copy ctor in MSVC2013, but it changed
to just the former in 2015. It looks like it changed back to the old
mangling in VS2017 version 15.7 and onwards, including VS2019 (version
16.0). VS2017 version 15.0 still has the VS2015 mangling. Versions
between 15.0 and 15.7 are't on godbolt. I found 15.4 (_MSC_VER 1911)
locally and that uses the 15.0 mangling still, but I didn't find 15.5 or
15.6, so I'm not sure where exactly it changed back.
Differential Revision: https://reviews.llvm.org/D62490
llvm-svn: 361959
The attribute pass_dynamic_object_size(n) behaves exactly like
pass_object_size(n), but instead of evaluating __builtin_object_size on calls,
it evaluates __builtin_dynamic_object_size, which has the potential to produce
runtime code when the object size can't be determined statically.
Differential revision: https://reviews.llvm.org/D58757
llvm-svn: 356515
This patch implements parsing and sema for "omp declare mapper"
directive. User defined mapper, i.e., declare mapper directive, is a new
feature in OpenMP 5.0. It is introduced to extend existing map clauses
for the purpose of simplifying the copy of complex data structures
between host and device (i.e., deep copy). An example is shown below:
struct S { int len; int *d; };
#pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper.
Contributed-by: Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D56326
llvm-svn: 352906
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
The msvc exception specifier for noexcept function types has changed
from the prior default of "Z" to "_E" if the function cannot throw when
compiling with /std:C++17.
Patch by Zachary Henkel!
Reviewers: zturner, rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55685
llvm-svn: 349414
All of the symbols demangle on llvm-undname and demangler.com. This
address space qualifier is useful for when we want to use opencl C++ in
Windows mode. Additionally, C++ address-space using functions will now
be usable on windows.
Differential Revision: https://reviews.llvm.org/D55715
Change-Id: Ife4506613c3cce778a783456d62117fbf7d83c26
llvm-svn: 349209
Address spaces are cast into generic before invoking the constructor.
Added support for a trailing Qualifiers object in FunctionProtoType.
Note: This recommits the previously reverted patch,
but now it is commited together with a fix for lldb.
Differential Revision: https://reviews.llvm.org/D54862
llvm-svn: 349019
Address spaces are cast into generic before invoking the constructor.
Added support for a trailing Qualifiers object in FunctionProtoType.
Differential Revision: https://reviews.llvm.org/D54862
llvm-svn: 348927
This patch breaks Index/opencl-types.cl LIT test:
Script:
--
: 'RUN: at line 1'; stage1/bin/c-index-test -test-print-type llvm/tools/clang/test/Index/opencl-types.cl -cl-std=CL2.0 | stage1/bin/FileCheck llvm/tools/clang/test/Index/opencl-types.cl
--
Command Output (stderr):
--
llvm/tools/clang/test/Index/opencl-types.cl:3:26: warning: unsupported OpenCL extension 'cl_khr_fp16' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:4:26: warning: unsupported OpenCL extension 'cl_khr_fp64' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:8:9: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:11:8: error: declaring variable of type 'half' is not allowed
llvm/tools/clang/test/Index/opencl-types.cl:15:3: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:16:3: error: use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:26:26: warning: unsupported OpenCL extension 'cl_khr_gl_msaa_sharing' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:35:44: error: use of type '__read_only image2d_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:36:49: error: use of type '__read_only image2d_array_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:37:49: error: use of type '__read_only image2d_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:38:54: error: use of type '__read_only image2d_array_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm-svn: 346338
We correctly handled extended vectors of non-floating point types.
However, we have the Intel style builtins which MSVC also supports which
do overlap in sizes with the floating point extended vectors. This
would result in overloading of floating point extended vector types
which matched sizes (e.g. <3 x float> would be backed by a <4 x float>
and thus match sizes) to be mangled similarly. Extended vectors are a
clang extension which live outside of the builtins, so mangle them all
similarly. This change just extends the current scheme to treat
floating point types similar to the way that we treat other types
currently.
This now allows the swift runtime to be built for Windows again.
llvm-svn: 345479
The generated MS manglings differ between 32- and 64-bit, and the test only
expects the latter. See also the commit email thread.
> Thanks to Cameron DaCamara at Microsoft for letting us know what their
> chosen mangling is here!
llvm-svn: 345380
As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes
to have the same mangling as C++ structs, to support headers like the
following:
```
@class I;
struct I;
void f(I *);
```
since the header can be used from both C++ and Obj-C++ TUs, and we want
a consistent mangling across the two to prevent link errors. Itanium
mangles both the same way, and so should the MS ABI.
The main concern with having the same mangling for C++ structs and Obj-C
classes was that we want to treat them differently for the purposes of
exception handling, e.g. we don't want a C++ catch statement for a
struct to be able to catch an Obj-C class with the same name as the
struct. We can accomplish this by mangling Obj-C class names differently
in their RTTI, which I'll do in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D52581
llvm-svn: 343808
Add support for encoding type arguments for lightweight generics in
Objective-C++ mode. Additionally, add support for the `__kindof` modifier.
This should complete the coverage of the ObjC extensions that clang currently
supports under the MS style name decoration scheme.
This is implemented similar to the Objective-C lifetime qualifiers decoration:
a template specialization in the `__ObjC` namespace so that we can interoperate
with Microsoft's tools as well as ensure that we do not accidentally collide
with new features in the Microsoft implementation.
Since the `__kindof` appertains to the type and not the pointer, we apply the
template specialization to the underlying type instead of the pointer type.
Unfortunately, until D52581 is resolved, the generated name is not really
compatible with the MS tools as well as breaks interoperability with
Objective-C++ and C++.
This resolves PR37754!
llvm-svn: 343338
There are two types of dynamic initializer stubs. There's
`dynamic initializer for 'x''(void)
and
`dynamic initializer for `static Foo::Bar StaticDataMember''(void)
The second case is disambiguated from the first by the presence of
a ? after the operator code. So the first will appear something like
?__E<name> while the second will appear something like ?__E?<name>.
clang-cl was mangling these both the same though. This patch
matches behavior with cl.
Differential Revision: https://reviews.llvm.org/D51500
llvm-svn: 341117
Summary:
This is needed to avoid conflicts in mangled names for codeview types in
anonymous namespaces. In CodeView, types refer to each other typically
through forward declarations, which contain mangled names. These names
have to be unique, otherwise the debugger will look up the mangled name
and find the wrong definition.
Furthermore, ThinLTO will deduplicate the types, and debug info
verification can fail when the types have the wrong sizes. This is
PR38608.
Fixes PR38609.
Reviewers: majnemer, inglorion, hans
Subscribers: mehdi_amini, aprantl, JDevlieghere, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50877
llvm-svn: 340079
This mangling is used only for outlined SEH finally blocks, which have
internal linkage.
This fixes the failure of CodeGenObjC/2007-04-03-ObjcEH.m on builds with
expensive checks enabled, on Windows. This test should probably be
specifying a triple: it currently picks up whatever the host environment
is using. Unfortunately, I have no idea what it is trying to test,
because it contains no comments and predates Clang having working
Objective-C IR generation.
llvm-svn: 339667
Summary:
Introduces funclet-based unwinding for Objective-C and fixes an issue
where global blocks can't have their isa pointers initialised on
Windows.
After discussion with Dustin, this changes the name mangling of
Objective-C types to prevent a C++ catch statement of type struct X*
from catching an Objective-C object of type X*.
Reviewers: rjmccall, DHowett-MSFT
Reviewed By: rjmccall, DHowett-MSFT
Subscribers: mgrang, mstorsjo, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D50144
llvm-svn: 339428
If QMM_Result is set (which it is for return types, RTTI descriptors, and
exception type descriptors), tag types (structs, enums, classes, unions) get
their qualifiers mangled in.
__m64 and friends is a struct/union thingy in MSVC, but not in clang's headers.
To make mangling work, we call mangleArtificalTagType(TTK_Union/TTK_Struct for
the vector types to mangle them as tag types -- but the isa<TagType> check when
mangling in QMM_Result mode isn't true for these vector types. Add an
isArtificialTagType() function and check for that too. Fixes PR37276 and some
other issues.
I tried to audit all references to TagDecl and TagType in MicrosoftMangle.cpp
to find other places where we need to call mangleArtificalTagType(), but
couldn't find any.
I tried to audit all calls to mangleArtificalTagType() to see if
isArtificialTagType() needs to handle more than just the vector types, but as
far as I can tell all other types we use it for are types that MSVC can't
handle at all (Objective-C types etc).
https://reviews.llvm.org/D49597
llvm-svn: 337732
As listed in the above PRs, vector_size doesn't allow
dependent types/values. This patch introduces a new
DependentVectorType to handle a VectorType that has a dependent
size or type.
In the future, ALL the vector-types should be able to create one
of these to handle dependent types/sizes as well. For example,
DependentSizedExtVectorType could likely be switched to just use
this instead, though that is left as an exercise for the future.
Differential Revision: https://reviews.llvm.org/D49045
llvm-svn: 337036
The member init list for the sole constructor for CodeGenFunction
has gotten out of hand, so this patch moves the non-parameter-dependent
initializations into the member value inits.
llvm-svn: 336726
A Chromium developer reported a bug which turned out to be a mangling
collision between these two literals:
char s[] = "foo";
char t[32] = "foo";
They may look the same, but for the initialization of t we will (under
some circumstances) use a literal that's extended with zeros, and
both the length and those zeros should be accounted for by the mangling.
This actually makes the mangling code simpler: where it previously had
special logic for null terminators, which are not part of the
StringLiteral, that is now covered by the general algorithm.
(The problem was reported at https://crbug.com/857442)
Differential Revision: https://reviews.llvm.org/D48928
llvm-svn: 336415
MSVC limits char16_t and char32_t string literal names to 32 bytes of character
data, not to 32 characters. wchar_t string literal names on the other hand can
get up to 64 bytes of character data.
https://reviews.llvm.org/D48781
llvm-svn: 336097
This diff includes changes for the remaining _Fract and _Sat fixed point types.
```
signed short _Fract s_short_fract;
signed _Fract s_fract;
signed long _Fract s_long_fract;
unsigned short _Fract u_short_fract;
unsigned _Fract u_fract;
unsigned long _Fract u_long_fract;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
short _Fract short_fract;
_Fract fract;
long _Fract long_fract;
// Saturated fixed point types
_Sat signed short _Accum sat_s_short_accum;
_Sat signed _Accum sat_s_accum;
_Sat signed long _Accum sat_s_long_accum;
_Sat unsigned short _Accum sat_u_short_accum;
_Sat unsigned _Accum sat_u_accum;
_Sat unsigned long _Accum sat_u_long_accum;
_Sat signed short _Fract sat_s_short_fract;
_Sat signed _Fract sat_s_fract;
_Sat signed long _Fract sat_s_long_fract;
_Sat unsigned short _Fract sat_u_short_fract;
_Sat unsigned _Fract sat_u_fract;
_Sat unsigned long _Fract sat_u_long_fract;
// Aliased saturated fixed point types
_Sat short _Accum sat_short_accum;
_Sat _Accum sat_accum;
_Sat long _Accum sat_long_accum;
_Sat short _Fract sat_short_fract;
_Sat _Fract sat_fract;
_Sat long _Fract sat_long_fract;
```
This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches.
Differential Revision: https://reviews.llvm.org/D46911
llvm-svn: 334718
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Fixed the test that was failing by not checking for dso_local on some
targets.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333923
```
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
```
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333814
Ensure latest MPT decl has a MSInheritanceAttr when instantiating
templates, to avoid null MSInheritanceAttr deref in
CXXRecordDecl::getMSInheritanceModel().
See PR#37399 for repo / details.
Patch by Andrew Rogers!
Differential Revision: https://reviews.llvm.org/D46664
llvm-svn: 333680
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
Half-type mangling is accomplished following the method introduced by Erich
Keane for mangling _Float16. Updated the half.cl LIT test to cover this
particular case.
Patch By: vbridgers
Differential Revision: https://reviews.llvm.org/D46131
llvm-svn: 331263
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
Enables _Float16 on Windows by creating a mangling
mechanism in MicrosoftMangle. It accomplishes this by
mangling as a structure type of __clang::_Float16, similar
to how Complex works.
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D45738
llvm-svn: 330225
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
Microsoft has reserved 'U' for the PreserveMostCC which is used in the
swift runtime. Add support for this. This allows the swift runtime to
be built for Windows again.
llvm-svn: 329025
This re-lands r328845 with fixes for crbug.com/827810.
The initial motiviation was to hoist MethodVFTableLocation to global
scope so it could be forward declared.
In this patch, I noticed that MicrosoftVTableContext uses some risky
patterns. It has methods that return references to data stored in
DenseMaps. I've made some of them return by value for trivial structs
and I've moved some things into separate allocations.
llvm-svn: 329007
This allows forward declaring it so that we can add it to
MicrosoftMangleContext::mangleVirtualMemPtrThunk without including
VTableBuilder.h. That saves a hashtable lookup when emitting virtual
member pointer functions.
It also shortens a really long type name. This struct has "VFtable" in
the name, so it seems pretty unlikely that someone will assume it is
generally useful for non-MS C++ ABI stuff.
llvm-svn: 328845
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.
Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).
I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.
llvm-svn: 326416
Adjust the ObjC protocol conformance workaround to be more extensible.
Use a synthetic type for the protocol (`struct Protocol`). Embed this
within a reserved namespace to permit extending the extended pointer
type qualifiers similarly for ObjC lifetime qualifiers.
Introduce additional special handling for `__autoreleasing`, `__strong`,
and `__weak` Objective C lifetime qualifiers. We decorate these by
creating an artificial template type `Autoreleasing`, `Strong`, or
`Weak` in the `__ObjC` namespace. These are only considered in the
template type specialization and not the function parameter.
llvm-svn: 324701
Microsoft has reserved the identifier 'S' as the swift calling
convention. Decorate the symbols appropriately. This enables swift on
Windows.
llvm-svn: 324439
Add support for mangling ObjC protocol conformances in MS ABI as if they are
COM interfaces. By diverging from the itanium mangling of `objc_protocol`
prefixed names, this approach allows for a semi-reasonable, albeit of
questionable sanity, undecoration via existing tooling. There is also the
possibility of adding an extension and taking part of the namespace to add the
conformance via the `L` and `Z` "modifiers", but the existing tooling would not
be able to properly undecorated the symbol even though incidentally `undname`
currently produces something legible while wine's implementation is not able to
cope with the extension.
This allows for the disambiguation of overloads where the parameter differs
only in the protocol conformance of the ObjC type, e.g.
```
@protocol P;
void f(std::vector<id>);
void f(std::vector<id<P>>);
```
which clang would previously fail due to the mangling being identical as the
protocol conformance was ignored.
llvm-svn: 323547
We would previously treat `SEL` as a pointer-only type. This is not the
case. It should be treated similarly to `id` and `Class`. Add some
test cases to ensure that it will be properly handled as well.
llvm-svn: 323257
Rather than hardcode the pointerness of the `id` and `class` types,
handle them generically. This allows for the template type
specialization of `remove_pointer<id>` which would look through the `id`
type and deal with the `objc_object` structure without the pointer.
llvm-svn: 323241
This patch relates to: https://reviews.llvm.org/D33666 This adds support
for template parameters to be passed to the address_space attribute.
The main goal is to add further flexibility to the attribute and allow
for it to be used easily with templates.
The main additions are a new type (DependentAddressSpaceType) alongside
its TypeLoc and its mangling. As well as the logic required to support
dependent address spaces which mainly resides in TreeTransform.h and
SemaType.cpp.
llvm-svn: 314649
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
`id` needs to be handled specially since it is a `TypedefType` which is
sugar for an `ObjCObjectPointerType` whose pointee is an
`ObjCObjectType` with base `BuiltinType::ObjCIdType` and no protocols
and the first level of pointer gets it own type implementation. `Class`
is similar with the `ObjCClassType` as the base instead.
The qualifiers on the base type of the `ObjCObjectType` need to be
dropped because the innermost `mangleType` will handle the qualifiers
itself.
`id` is desugared to `struct objc_object *` which should be encoded as
`PAUobjc_object@@`. `Class` is desugared to `struct objc_class *` which
should be encoded as `PAUobjc_class@@`.
We were previously applying an extra modifier `A` which will be handled
during the recursive call.
This now properly decorates interface types as well as `Class` and `id`.
This corrects the interactions between C++ and ObjC++ for the type
specifier decoration.
llvm-svn: 311617
Move builtins from the x86 specific scope into the global
scope. Their use is still limited to x86_64 and aarch64 though.
This allows wine on aarch64 to properly handle variadic functions.
Differential Revision: https://reviews.llvm.org/D34475
llvm-svn: 308218
When generating the decorated name for a static variable inside a
BlockDecl, construct a scope for the block invocation function that
homes the parameter. This allows for arbitrary nesting of the blocks
even if the variables are shadowed. Furthermore, using this for the name
allows for undname to properly undecorated the name for us. It shows up
as the synthetic __block_invocation function that the compiler emitted
in the local scope.
llvm-svn: 306347
Removed ndrange_t as Clang builtin type and added
as a struct type in the OpenCL header.
Use type name to do the Sema checking in enqueue_kernel
and modify IR generation accordingly.
Review: D28058
Patch by Dmitry Borisenkov!
llvm-svn: 295311
They are a little bit of a special case in the mangling. They are always
mangled without taking into account their virtual-ness of the
destructor. They are also mangled to return void, unlike the actual
destructor.
This fixes PR31931.
Differential Revision: https://reviews.llvm.org/D29912
llvm-svn: 295010
We model deduction-guides as functions with a new kind of name that identifies
the template whose deduction they guide; the bulk of this patch is adding the
new name kind. This gives us a clean way to attach an extensible list of guides
to a class template in a way that doesn't require any special handling in AST
files etc (and we're going to need these functions we come to performing
deduction).
llvm-svn: 294266
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
Use the canonical decl in pointer comparisons with the default
constructor closure decl. Otherwise we don't produce the correct
"@@QAEXXZ" mangling, which essentially means "void(void) thiscall public
instance method".
llvm-svn: 291448
We didn't implement handle corner cases like:
- lambdas used to initialize a field
- lambdas in default argument initializers
This fixes PR31197.
Differential Revision: https://reviews.llvm.org/D27226
llvm-svn: 288826
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
We need to mark the appropriate bits in ThrowInfo and HandlerType so
that the personality routine can correctly handle qualification
conversions.
llvm-svn: 275154
It seems that suffix '@4HA' was omitted for unknown reason. It is
non-cont non-volatile 'int' type of normal variable TSS.
Differential revision: http://reviews.llvm.org/D20683
llvm-svn: 270974
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
llvm-svn: 270834
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
llvm-svn: 269220
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
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
Nico Weber