llvm-svn: 121021

the instruction is predicated, reg0 otherwise.

llvm-svn: 121020

    o test_many_expr_commands()
    o test_expr_commands_can_handle_quotes()

Mark test_expr_commands_can_handle_quotes()
as @expectedFailure:

    # rdar://problem/8686536
    # CommandInterpreter::HandleCommand is stripping \'s from input for WantsRawCommand commands

llvm-svn: 121019

not an immediate. It stores either ARM::CPSR or reg0.

llvm-svn: 121018

This time for .s file.

llvm-svn: 121016

Use Sema's MarkDeclarationReferenced, which takes care of templates, instead of calling Decl's setUsed directly.
Thanks to John for the hint!

llvm-svn: 121014

Use the source location of the parameter, when it makes sense, for diagnostics in HandleCleanupAttr.

llvm-svn: 121013

and visibility of declarations, because it was extremely messy and it
increased the size of NamedDecl.

An improved implementation is forthcoming.

llvm-svn: 121012

routines.

llvm-svn: 121007

as llc + llvm-mc. This time ELF is not changed and I tested that llvm-gcc
bootstrap on darwin10 using darwin9's assembler and linker.

llvm-svn: 121006

linux and darwin assemblers happy :-(

llvm-svn: 121004

llvm-svn: 121002

llvm-svn: 121001

that no relocations are used (on MochO).
Fixes llc producing different output from llc + llvm-mc.

llvm-svn: 121000

llvm-svn: 120998

so that's not a valid thing to do at all. Instead, switch to a ValueDecl
argument, the template isn't really necessary here.

When handling the types explicitly in the code, it becomes awkward to cerate
the CXXBaseOrMemberInitializer object in so many places. Re-flow the code to
calculate the Init expression first, and then create the initializer. If this
is too gross, we can factor the init expression logic into helper functions,
but it's not past my threshold yet.

llvm-svn: 120997

reason this is limited to C++, and it's certainly not limited to temporaries.

llvm-svn: 120996

optimization.

Consider:
static void foo() {
  A = alloca
  ...
}

static void bar() {
  B = alloca
  ...
  call foo();
}

void main() {
  bar()
}

The inliner proceeds bottom up, but lets pretend it decides not to inline foo
into bar.  When it gets to main, it inlines bar into main(), and says "hey, I
just inlined an alloca "B" into main, lets remember that.  Then it keeps going
and finds that it now contains a call to foo.  It decides to inline foo into
main, and says "hey, foo has an alloca A, and I have an alloca B from another
inlined call site, lets reuse it".  The problem with this of course, is that 
the lifetime of A and B are nested, not disjoint.

Unfortunately I can't create a reasonable testcase for this: the one in the
PR is both huge and extremely sensitive, because you minor tweaks end up
causing foo to get inlined into bar too early.  We already have tests for the
basic alloca merging optimization and this does not break them.

llvm-svn: 120995

llvm-svn: 120994

llvm-svn: 120993

the LHS, or else the pointer might be invalid.  This is kindof dumb, but
go ahead and make sure we're doing that for l-value scalar assignment,
which fixes a miscompile of obj-c++.dg/block-seq.mm.

Leave a FIXME for how to solve this problem for agg __blocks.

llvm-svn: 120992

llvm-svn: 120991

build one when either of the operands calls itself type-dependent;
previously we were building when one of the operand types was dependent,
which is not always the same thing and which can lead to unfortunate
inconsistencies later.  Fixes PR8739.

llvm-svn: 120990

llvm-svn: 120989

llvm-svn: 120988

llvm-svn: 120987

llvm-svn: 120986

llvm-svn: 120985

implementation needs it for wchar_t and SmallVectorImpl in general.

llvm-svn: 120984

llvm-svn: 120982

that on the ELF writer to detect a section we created.

llvm-svn: 120981

llvm-svn: 120980

llvm-svn: 120979

llvm-svn: 120978

llvm-svn: 120977

Add bug number for current expected failures.

llvm-svn: 120976

more completely. Example expressions are in the comments.

llvm-svn: 120975

memcpy's like:
  memcpy(A, B)
  memcpy(A, C)

we cannot delete the first memcpy as dead if A and C might be aliases.
If so, we actually get:

  memcpy(A, B)
  memcpy(A, A)

which is not correct to transform into:

  memcpy(A, A)

This patch was heavily influenced by Jakub Staszak's patch in PR8728, thanks
Jakub!

llvm-svn: 120974

llvm-svn: 120973

(for example, string literals) were being flagged
erroneously as undefined external variables.

llvm-svn: 120972