llvm-svn: 127006

llvm-svn: 127005

DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.

Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).

How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?

I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.

llvm-svn: 127004

llvm-svn: 127003

template <class T> void foo();
template <> void foo<int>(); /* Spec 1 */
template <> void foo<int>(); /* Spec 2 */

If we look at the main location of the first explicit specialization (Spec 1) it can be seen that it points to the name of the *second* explicit specialization (Spec 2), which is a redeclaration of Spec1.
Hence, the source range obtained for Spec1 is not only inaccurate, but also invalid (the end location comes before the start location).

llvm-svn: 127002

type after type legalization has completed.  Before then it may simply not be big
enough to hold the shift amount, particularly on x86 which uses a very small type
for shifts (this issue broke stuff in the past which is why LegalizeTypes carefully
uses a large type for shift amounts).

llvm-svn: 127000

llvm-svn: 126999

There was a previous implementation with patterns that would 
have matched e.g. 
	shl <v4i32> <i32>,
but this is not valid LLVM IR so they never were selected.

llvm-svn: 126998

llvm-svn: 126997

llvm-svn: 126996

A 'load <4 x i32>* null' crashes llc before this fix.

llvm-svn: 126995

llvm-svn: 126994

llvm-svn: 126993

computing for a nested decl with explicit visibility.  This is all part
of the general philosophy of explicit visibility attributes, where
any information that was obviously available at the attribute site
should probably be ignored.  Fixes PR9371.

llvm-svn: 126992

in the urem case, though not the other way around. This is enough to get #3 from
PR9343!

llvm-svn: 126991

this can have any optimization effect, given the opacity of objects pointers,
but you never know.

llvm-svn: 126990

llvm-svn: 126989

"icmp pred %X, CI" and a number of examples where "%X = binop %Y, CI2".

Some of these cases (div and rem) used to make it through opt -O2, but the
others are probably now making code elsewhere redundant (probably instcombine).

llvm-svn: 126988

llvm-svn: 126987

bugs with such types.  Not sure this is quite how I want the desugaring
and a.k.a. logic to go, but it suffices.

llvm-svn: 126986

Avoid colliding with the sentinels, hopefully unbreaking
llvm-gcc-x86_64-linux-selfhost.

llvm-svn: 126982

Fix the PendingQueue, then disable it because it's not required for
the current schedulers' heuristics.
Fix the logic for the unused list-ilp scheduler.

llvm-svn: 126981

llvm-svn: 126980

on the command line.  For example, use '-A x86_64^i386' to launch the inferior use both x86_64
and i386.

This is an example of building the debuggee using both clang and gcc compiers:

[17:30:46] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging

Session logs for test failures/errors will go into directory '2011-03-03-17_31_39'
Command invoked: python ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging

Configuration:  compiler=clang
----------------------------------------------------------------------
Collected 1 test

1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase)
   Modify a source file while debugging the executable. ... Command 'run' failed!

original content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

new content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello lldb.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after writing new content: 1299202305.0
content restored to: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after restore: 1299202307.0
ok

----------------------------------------------------------------------
Ran 1 test in 8.259s

OK

Configuration:  compiler=gcc
----------------------------------------------------------------------
Collected 1 test

1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase)
   Modify a source file while debugging the executable. ... original content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

new content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello lldb.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after writing new content: 1299202307.0
content restored to: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after restore: 1299202309.0
ok

----------------------------------------------------------------------
Ran 1 test in 2.301s

OK
[17:31:49] johnny:/Volumes/data/lldb/svn/trunk/test $ 

llvm-svn: 126979

llvm-svn: 126978

Correctly handle nested switch statements in CFGBuilder when on switch statement has a condition that evaluates to a constant.

llvm-svn: 126977

llvm-svn: 126975

Patch verified by Greg Clayton prior to checkin.

llvm-svn: 126974

or 'self' variable was not properly read if the compiler
optimized it into a register.

llvm-svn: 126973

This speeds up updateSSA() so it only accounts for 5% of the live range
splitting time.

llvm-svn: 126972

llvm-svn: 126970

it. It's been assumed up til now that it would be in its immediate
successor. However, this isn't necessarily the case. It could be in one of its
successor's successors.

Modify the code to more thoroughly check for an 'eh.selector' call in
successors. It only looks at a successor if we get there as a result of an
unconditional branch.

Testcase ObjC/exceptions-4.m in r126968.

llvm-svn: 126969

Patch by Zonr Chang!

llvm-svn: 126967

-Woverloaded-virtual shouldn't warn for static functions. Fixes rdar://9083431 & http://llvm.org/PR9396.

llvm-svn: 126966

Add code to emulate RFE Arm instruction.

Add new instruction context for RFE instruction.

Add several new helper functions to help emulate RFE instruction
(including CurrentModeIsPrivileged, BadMode, and CPSRWriteByInstr).

llvm-svn: 126965

llvm-svn: 126964

llvm-svn: 126963

llvm-svn: 126962

  1) When we do an instantiation of the injected-class-name type,
  provide a proper source location. This is just plain good hygiene.

  2) When we're building a NestedNameSpecifierLoc from a CXXScopeSpec,
  only return an empty NestedNameSpecifierLoc if there's no
  representation.

Both problems contributed to the horrible test case in PR9390 that I
couldn't reduce down to something palatable.

llvm-svn: 126961

This fixes few blocks.exp regressions.

llvm-svn: 126960