That particular optimization was probably premature anyway.

llvm-svn: 161541

method/c-funcs defined in objc class implementation.
No intended functionality change.

llvm-svn: 161540

llvm-svn: 161539

suitable for building as part of the LLVM/Clang build.

llvm-svn: 161538

llvm-svn: 161537

Allow legalization of target-specific SDNodes, provided that the target itself provide a legalization hook for them.

llvm-svn: 161536

Handle deprecation diagnostics correctly for C struct fields and Objective-C properties/ivars. <rdar://problem/6642337>.

llvm-svn: 161534

Fixed the delay that was happening when quitting lldb from the command line. We weren't initializing the command pipes when constructing a ConnectionFileDescriptor with a file descriptor.

llvm-svn: 161533

We filter out MachineLoop back-edges during the trace-building PO
traversals, but it is possible to have CFG cycles that aren't natural
loops, and MachineLoopInfo doesn't include such cycles.

Use a standard visited set to detect such CFG cycles, and completely
ignore them when picking traces.

llvm-svn: 161532

not compress spaces in verbatim content.

llvm-svn: 161531

llvm-svn: 161530

llvm-svn: 161529

Unify the codepaths for emitting deprecation warnings.  The test changes are just to account for us emitting notes more consistently.

llvm-svn: 161528

llvm-svn: 161527

llvm-svn: 161526

We handled the builtin version of this function in r157968, but the builtin
isn't used when compiling as -fno-constant-cfstrings.

This should complete <rdar://problem/6157200>.

llvm-svn: 161525

only machine specific clobbers are modeled.

llvm-svn: 161524

are not definitions. This follows the behavior of both gcc and earlier
versions of clang. Regression from r156531.  <rdar://problem/12048621>.

llvm-svn: 161523

llvm-svn: 161522

llvm-svn: 161521

crashers at the moment (and coincidentally this case was causing a crash).

llvm-svn: 161520

I don't have a win32 system to test, so hopefully I got them all fixed here.

llvm-svn: 161519

functional change intended.

llvm-svn: 161518

llvm-svn: 161517

llvm-svn: 161516

- The defines are in stddint.h, which is #include'd already.
- The block wasn't used anyway, since it was _OpenBSD_, and not __OpenBSD__

Patch by David Hill!

llvm-svn: 161515

includes the proper license text.

llvm-svn: 161514

llvm-svn: 161513

Unfortunately, generalized region printing is very difficult:
- ElementRegions are used both for casting and as actual elements.
- Accessing values through a pointer means going through an intermediate
  SymbolRegionValue; symbolic regions are untyped.
- Referring to implicitly-defined variables like 'this' and 'self' could be
  very confusing if they come from another stack frame.

We fall back to simply not printing the region name if we can't be sure it
will print well. This will allow us to improve in the future.

llvm-svn: 161512

The main blocker on this (besides the previous commit) was that
ScanReachableSymbols was not looking through LazyCompoundVals.
Once that was fixed, it's easy enough to clear out malloc data on return,
just like we do when we bind to a global region.

<rdar://problem/10872635>

llvm-svn: 161511

RegionStore currently uses a (Region, Offset) pair to describe the locations
of memory bindings. However, this representation breaks down when we have
regions like 'array[index]', where 'index' is unknown. We used to store this
as (SubRegion, 0); now we mark them specially as (SubRegion, SYMBOLIC).

Furthermore, ProgramState::scanReachableSymbols depended on the existence of
a sub-region map, but RegionStore's implementation doesn't provide for such
a thing. Moving the store-traversing logic of scanReachableSymbols into the
StoreManager allows us to eliminate the notion of SubRegionMap altogether.

This fixes some particularly awkward broken test cases, now in
array-struct-region.c.

llvm-svn: 161510

No functionality change. A couple ugly const_casts because the ancestor
search code is used for other purposes as well.

llvm-svn: 161509

asm statements are those that don't reference variable names, function names,
and labels.

Add logic to generate a patched AsmString that will eventually be consumed by
the AsmParser.  No functional change at this point, so unfortunately no test
case.

llvm-svn: 161508

Thanks, Andy!

llvm-svn: 161507

Also test the commit hooks for the new repository.

llvm-svn: 161506

llvm-svn: 161505

This patch allows us to use cmake to specify a cross compiler for Hexagon.

In particular, the patch adds a missing case for the target Hexagon in
cmake/config-ix.cmake, and it moves LLVM_DEFAULT_TARGET_TRIPLE and TARGET_TRIPLE
variables from cmake/config-ix.cmake to the toplevel CMakeLists.txt to make them
available at configure time. Here is the command line that I have used to test
my patches:

$ cmake -G Ninja -D BUILD_SHARED_LIBS:BOOL=ON -D LLVM_TARGETS_TO_BUILD:STRING=Hexagon -D TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_DEFAULT_TARGET_TRIPLE:STRING=hexagon-unknown-linux-gnu -D LLVM_TARGET_ARCH:STRING=hexagon-unknown-linux-gnu -D LLVM_ENABLE_PIC:BOOL=OFF ..
$ ninja check

llvm-svn: 161504

llvm-svn: 161503

suppress all non-error output from the "expression"
command.

<rdar://problem/11225150>

llvm-svn: 161502

This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...

There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.

Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.

Review by Sean Silva and Richard Smith.

llvm-svn: 161501