llvm-svn: 133561

There could be more than one DBG_VALUE instructions for variables where all of them have offset based on one register.

llvm-svn: 133560

explanation of what the EH table describes.

llvm-svn: 133559

llvm-svn: 133557

llvm-svn: 133556

use the unresolved-name production correctly.

llvm-svn: 133554

Noticed on inspection.

llvm-svn: 133553

llvm-svn: 133551

use an "IgnoreSysRoot" argument.  HeaderSearchOptions had been using the
opposite form with "IsSysRootRelative", which made for much confusion when
looking at true/false values in calls in AddPath.  No functional change.

llvm-svn: 133550

llvm-svn: 133548

The -cxx-isystem path is not prefixed with the sysroot directory, so it's
not a good way for the driver to set the system default C++ search path.
Instead, add -stdlib as a cc1 option and teach the frontend how to find the
headers.  The driver can then just pass -stdlib through to "cc1".

llvm-svn: 133547

llvm-svn: 133546

that the linker has a place to put the temporary object file and can leave it
around (for the driver to clean up). This is important so that the object file
references in the debug info are preserved for possible use by dsymutil.
 - <rdar://problem/8294279> executable has no debug symbols when compiled with LTO

llvm-svn: 133543

llvm-svn: 133542

llvm-svn: 133541

[arcmt] Merge 'removeEmptyStatements' and 'removeDeallocMethod' passes to cut down on one compilation
pass and increase migration speed.

llvm-svn: 133540

llvm-svn: 133539

rdar://problem/9649573 has captured the log files when running test_long_long_type_with_dsym() (which luckily failed) and the test session files for test failures.

llvm-svn: 133538

with no delay between successive test cases.  This one happend to capture a test failure where
the inferior shoud stop at a breakpoint but did not (radar will be filed to capture the log files
as well as the test session files):

[12:40:37] johnny:/Volumes/data/lldb/svn/trunk/test $ DEBUG_LLDB_LOG=/tmp/lldb.log DEBUG_GDB_REMOTE_LOG=/tmp/gdb-remote.log ./dotest.py -v -p TestFailures.py
LLDB-63
Path: /Volumes/data/lldb/svn/trunk
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 133529
Node Kind: directory
Schedule: normal
Last Changed Author: jmolenda
Last Changed Rev: 133500
Last Changed Date: 2011-06-20 19:57:15 -0700 (Mon, 20 Jun 2011)



Session logs for test failures/errors/unexpected successes will go into directory '2011-06-21-12_40_42'
Command invoked: python ./dotest.py -v -p TestFailures.py
----------------------------------------------------------------------
Collected 10 tests

 1: test_char_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
    Test that char-type variables are displayed correctly. ... ok
 2: test_char_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
    Test that char-type variables are displayed correctly. ... ok
 3: test_int_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
    Test that int-type variables are displayed correctly. ... ok
 4: test_int_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
    Test that int-type variables are displayed correctly. ... ok
 5: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
    Test that 'long long'-type variables are displayed correctly. ... FAIL
 6: test_long_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
    Test that 'long long'-type variables are displayed correctly. ... ok
 7: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
    Test that long-type variables are displayed correctly. ... TestFailures.DebugIntegerTypesFailures.test_long_type_with_dsym
FAIL
 8: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
    Test that long-type variables are displayed correctly. ... FAIL
 9: test_short_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
    Test that short-type variables are displayed correctly. ... ok
10: test_short_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
    Test that short-type variables are displayed correctly. ... ok

======================================================================
FAIL: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
    Test that 'long long'-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 102, in test_long_long_type_with_dsym
    self.long_long_type()
  File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 129, in long_long_type
    self.generic_type_tester(set(['long long']))
  File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
    "stop reason = breakpoint"])
  File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
    msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint

======================================================================
FAIL: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
    Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 87, in test_long_type_with_dsym
    self.long_type()
  File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
    self.generic_type_tester(set(['long']))
  File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
    "stop reason = breakpoint"])
  File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
    msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint

======================================================================
FAIL: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
    Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 94, in test_long_type_with_dwarf
    self.long_type()
  File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
    self.generic_type_tester(set(['long']))
  File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
    "stop reason = breakpoint"])
  File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
    msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint

----------------------------------------------------------------------
Ran 10 tests in 5.617s

FAILED (failures=3)
Session logs for test failures/errors/unexpected successes can be found in directory '2011-06-21-12_40_42'
[12:40:47] johnny:/Volumes/data/lldb/svn/trunk/test $ 

llvm-svn: 133537

llvm-svn: 133536

__builtin___CFStringMakeConstantString and CF typed function calls 
with explicit cf_returns_retained/cf_returns_not_retained attributes.
// rdar://9544832

llvm-svn: 133535

Fix the log channel for gdb-remote.  It should be "gdb-remote" now, instead of "process.gdb-remote".

llvm-svn: 133534

llvm-svn: 133533

 - Changes bit-field access policy to try to use (aligned) register sized accesses.

The idea here is that by using larger accesses we expose more coalescing
potential to the backend when we have situations like adjacent bit-fields in the
same structure (which is common), and that the backend should be smart enough to
narrow the accesses down when no coalescing is done or when it is shown not to
be profitable.

--
$ clang -m32 -O3 -S -o - t.c
_f0:                                    ## @f0
	pushl	%ebp
	movl	%esp, %ebp
	movl	8(%ebp), %eax
	movb	(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, (%eax)
	movb	1(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, 1(%eax)
	movb	2(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, 2(%eax)
	movb	3(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, 3(%eax)
	popl	%ebp
	ret

$ clang -m32 -O3 -S -o - t.c -Xclang -fuse-register-sized-bitfield-access
_f0:                                    ## @f0
	pushl	%ebp
	movl	%esp, %ebp
	movl	8(%ebp), %eax
	movl	$-2139062144, %ecx      ## imm = 0xFFFFFFFF80808080
	andl	(%eax), %ecx
	orl	$16843009, %ecx         ## imm = 0x1010101
	movl	%ecx, (%eax)
	popl	%ebp
	ret
--

llvm-svn: 133532

 - For clarity only, currently just assumes register width == long width.

llvm-svn: 133531

llvm-svn: 133530

llvm-svn: 133529

llvm-svn: 133528

Expr value not getting changed by this call.

llvm-svn: 133527

of: a + b ? x : y. In our testing of this flag we've yet to hit a single
case where the existing precedence was correct, so we should suggest
grouping the ?: first.

llvm-svn: 133526

// rdar://9474349

llvm-svn: 133525

This is breaking compiler-rt and llvm-gcc builds on MacOSX when not using
the integrated assembler.

llvm-svn: 133524

expression of '?:'. Add a test case for this pattern, and also test the
code that led to the crash in a "working" case as well.

llvm-svn: 133523

Add support for sadd.with.overflow and uadd.with.overflow intrinsics to the CBackend by emitting definitions for each intrinsic that occurs in the module.

llvm-svn: 133522

MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given

  const int& r = 1.0;

The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value. 

IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.

llvm-svn: 133521

llvm-svn: 133518

llvm-svn: 133517

llvm-svn: 133516

use the deprecated forms of llvm::StringMap::GetOrCreateValue().

llvm-svn: 133515

llvm-svn: 133514