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

generation when we're dealing with an implicitly-defined copy or move
constructor. And, actually set the implicitly-defined bit for
implicitly-defined constructors and destructors. Should fix self-host.

llvm-svn: 140334

they still need the logic to cope with array member
initialization. Fixes PR10720.

llvm-svn: 140302

if the definition has a non-variadic prototype with compatible
parameters.  Therefore, the default rule for such calls must be to
use a non-variadic convention.  Achieve this by casting the callee to
the function type with which it is required to be compatible, unless
the target specifically opts out and insists that unprototyped calls
should use the variadic rules.  The only case of that I'm aware of is
the x86-64 convention, which passes arguments the same way in both
cases but also sets a small amount of extra information;  here we seek
to maintain compatibility with GCC, which does set this when calling
an unprototyped function.

Addresses PR10810 and PR10713.

llvm-svn: 140241

Change "ivar" to true for a boolean function argument.  Since string literals are cast to true, this should no effect on behavior.

llvm-svn: 140231

UnwindException structure is 32 for mips64. 

llvm-svn: 140165

llvm-svn: 140161

llvm-svn: 140123

Add list initialization for complex numbers in C.  Essentially, this allows "_Complex float x = {1.0f, 2.0f};".  See changes to docs/LanguageExtensions.html for a longer description.

<rdar://problem/9397672>.

llvm-svn: 140090

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

llvm-svn: 140068

instead of getLocation() since we don't care about expanded macro arguments.

llvm-svn: 140061

It already works (and is useful with) macro locs as well.

llvm-svn: 140057

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

Radar 10139522 - Part 1.

llvm-svn: 140038

instead of internal linkage.

llvm-svn: 140030

has no effect since any such destructors must be trivial, and in C++11 such destructors must not
be called.

llvm-svn: 139997

storage slot into helper functions.

llvm-svn: 139826

possible for that to matter right now, but eventually I think we'll
need to unify this better, and then it might.  Also, use a more
efficient looping structure.

llvm-svn: 139788

llvm-svn: 139770

we don't need to.

llvm-svn: 139769

llvm-svn: 139752

llvm-svn: 139681

llvm-svn: 139678

llvm-svn: 139668

the builtin is really just a predefined declaration.  These are
totally valid to cast.

llvm-svn: 139657

Make clang use Acquire loads and Release stores where necessary.

llvm-svn: 139650

llvm-svn: 139648

llvm-svn: 139643

Turn off the generation of unaligned atomic load/store; I'm going to explicitly error out on such cases in the backend, at least for the moment.

llvm-svn: 139640

their semantic attributes and then to take advantage of that.

llvm-svn: 139615

language options. Use that .def file to declare the LangOptions class
and initialize all of its members, eliminating a source of annoying
initialization bugs.

AST serialization changes are next up.

llvm-svn: 139605

even on architectures that support unaligned access (which is the
only way this is otherwise legal, given that ivars apparently do
not honor alignment attributes).

llvm-svn: 139590

llvm-svn: 139585

atomic.  This is probably something we should warn about.

llvm-svn: 139584

single code path.  Use atomic loads and stores where necessary.  Load and
store anything of the appropriate size and alignment with primitive
operations instead of going through the call.

llvm-svn: 139580

modernization.  No functionality change.

llvm-svn: 139555

llvm-svn: 139521

llvm-svn: 139514

llvm-svn: 139502