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
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
Richard Smith