llvm-svn: 121040

within the file 'filename'.

llvm-svn: 121039

llvm-svn: 121038

Address more hazards in the MBlaze delay slot filler.

patch contributed by Jack Whitham!

llvm-svn: 121037

'process load' and 'process unload' to load and unload shared library from lldb command
lines.

llvm-svn: 121036

FunctionArrayLvalueConversion but without the function/array decay.  Generally
this is only appropriate for use sites that know the type of the expression
and thus that it can't be subject to the decays.

Also make sure we do lvalue-to-rvalue on the bases of ivar references.

llvm-svn: 121035

llvm-svn: 121034

Add "clang indent" as a possible project, we really really 
need it. :)

llvm-svn: 121030

llvm-svn: 121029

freed data to be read. I will open a bug to track it being reenabled.

llvm-svn: 121028

llvm-svn: 121027

llvm-svn: 121026

introduced in r121023.

llvm-svn: 121025

llvm-svn: 121024

My previous attempt at solving the compile-time problem with many
redeclarations of the same entity cached both linkage and visibility,
while this patch only tackles linkage. There are several reasons for
this difference:

  - Linkage is a language concept, and is evaluated many times during
    semantic analysis and codegen, while visibility is only a
    code-generation concept that is evaluated only once per (unique)
    declaration. Hence, we *must* optimize linkage calculations but
    don't need to optimize visibility computation.
  - Once we know the linkage of a declaration, subsequent
    redeclarations can't change that linkage. Hence, cache
    invalidation is far simpler than for visibility, where a later
    redeclaration can completely change the visibility.
  - We have 3 spare bits in Decl to store the linkage cache, so the
    cache doesn't increase the size of declarations. With the
    visibility+linkage cache, NamedDecl got larger.

llvm-svn: 121023

Fixes PR8742.

llvm-svn: 121022

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