| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
It used to point to the first call that caused the landing pad to
be generated.
rdar://problem/13888152
llvm-svn: 181958
|
|
|
|
|
|
| |
used as a branch condition.
llvm-svn: 181368
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
llvm-svn: 176656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
|
|
|
|
|
|
| |
calling std::terminate(). rdar://11904428
llvm-svn: 174940
|
|
|
|
| |
llvm-svn: 174939
|
|
|
|
|
|
|
|
|
|
| |
Manually fix the order of UnwrappedLineParser.cpp as that one didn't
have its associated header as the first header.
This also uncovered a subtle inclusion order dependency as CLog.h didn't
include LLVM.h to pick up using declarations it relied upon.
llvm-svn: 172892
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
| |
Objective-C runtime 1.7 or greater.
llvm-svn: 172207
|
|
|
|
|
|
|
| |
an objectiveC object, use objc_exception_throw
to raise the exception. // rdar://12605907
llvm-svn: 172091
|
|
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
|
|
|
|
|
| |
which is not coincidentally the only place it works, either (because
of how it tests for EH_TYPE symbols).
llvm-svn: 167935
|
|
|
|
|
|
|
| |
a bug in the inliner still causes the wrong thing to happen at -O2 and above
(PR14116).
llvm-svn: 167534
|
|
|
|
| |
llvm-svn: 160102
|
|
|
|
|
|
| |
runtime to gnustep from gnu. Fix EH for the GCC runtime.
llvm-svn: 159684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
|
|
|
|
|
|
|
|
|
|
| |
semantics of a ctor/dtor function-try-block catch handler
by pushing a normal cleanup is not just overkill but actually
actively wrong when the handler contains an explicit return
(which is only legal in a dtor). Just emit the rethrow as
ordinary code at the fallthrough point. Fixes PR13102.
llvm-svn: 158488
|
|
|
|
|
|
| |
testers.
llvm-svn: 153660
|
|
|
|
|
|
|
| |
a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value. Fixes PR12204.
llvm-svn: 153613
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
| |
llvm-svn: 150919
|
|
|
|
|
|
|
|
| |
other users.
While at it make it value-initializable to get rid of static ctors.
llvm-svn: 150070
|
|
|
|
|
|
| |
CodeGenModule.
llvm-svn: 149943
|
|
|
|
| |
llvm-svn: 148577
|
|
|
|
|
|
|
|
|
| |
or whatever else is required for the initialization instead of
assuming it can be done with a simple store.
Fixes PR11732.
llvm-svn: 148325
|
|
|
|
| |
llvm-svn: 146202
|
|
|
|
|
|
| |
review comment.
llvm-svn: 145741
|
|
|
|
|
|
| |
I'll be introducing uses of the specified alignment soon.
llvm-svn: 145736
|
|
|
|
|
|
|
|
|
|
| |
need to provide a 'dominating IP' which is guaranteed to
dominate the (de)activation point but which cannot be avoided
along any execution path from the (de)activation point to
the push-point of the cleanup. Using the entry block is
bad mojo.
llvm-svn: 144276
|
|
|
|
|
|
|
|
|
| |
It's not valid to remove filters from landingpad instructions, even if we catch
the type. The metadata won't be set up correctly.
Testcase is projects/llvm-test/SingleSource/UnitTests/EH/filter-2.cpp.
llvm-svn: 140335
|
|
|
|
| |
llvm-svn: 140123
|
|
|
|
|
|
|
|
|
| |
check for the landingpad instruction instead. This check looks at each of the
clauses in the landingpad instruction. If it's a catch clause, it compares the
name directly with the global. If it's a filter clause, it has to look through
each value in the filer to see if any have the prefix.
llvm-svn: 140075
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This model uses the 'landingpad' instruction, which is pinned to the top of the
landing pad. (A landing pad is defined as the destination of the unwind branch
of an invoke instruction.) All of the information needed to generate the correct
exception handling metadata during code generation is encoded into the
landingpad instruction.
The new 'resume' instruction takes the place of the llvm.eh.resume intrinsic
call. It's lowered in much the same way as the intrinsic is.
llvm-svn: 140049
|
|
|
|
|
|
| |
storage slot into helper functions.
llvm-svn: 139826
|
|
|
|
|
|
|
|
| |
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
|
|
|
|
| |
llvm-svn: 138707
|
|
|
|
| |
llvm-svn: 138615
|
|
|
|
|
|
|
| |
creators to tell us whether something needs GC barriers.
No functionality change.
llvm-svn: 138581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hierarchy of delegation, and that EH selector values are meaningful
function-wide (good thing, too, or inlining wouldn't work).
2,3d
1a
hierarchy of delegation and that EH selector values have the same
meaning everywhere in the function instead of being meaningful only
in the context of a specific selector.
This removes the need for routing edges through EH cleanups,
since a cleanup simply always branches to its enclosing scope.
llvm-svn: 137293
|
|
|
|
| |
llvm-svn: 136461
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
| |
llvm-svn: 135370
|
|
|
|
| |
llvm-svn: 135265
|
|
|
|
|
|
| |
of flags. No functionality change.
llvm-svn: 134997
|
|
|
|
|
|
| |
people write useful cleanup classes.
llvm-svn: 134942
|
|
|
|
| |
llvm-svn: 134880
|
|
|
|
| |
llvm-svn: 134831
|
|
|
|
|
|
|
| |
exception in Objective-C; in Objective-C++ we still use std::terminate().
This is only available in very recent runtimes.
llvm-svn: 134456
|
|
|
|
|
|
| |
in fragile abi mode and some other cleanups. // rdar://8940528
llvm-svn: 133747
|
|
|
|
|
|
| |
in Darwin's fragile abi mode. // rdar://8940528
llvm-svn: 133639
|