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

-Wdirect-ivar-access.

llvm-svn: 161500

llvm-svn: 161498

Change size of reference count field in __libcpp_nmstr from 32 bits to 64 bits for 64 bit targets.  This is controls the data layout of all exceptions defined in <stdexcept>.  This aligns the ABI with that of gcc-4.2.

llvm-svn: 161497

Change size of reference count field in __libcpp_nmstr from 32 bits to 64 bits for 64 bit targets.  This is controls the data layout of all exceptions defined in <stdexcept>.  This aligns the ABI with that of gcc-4.2.

llvm-svn: 161496

Add some tests for __OPTIMIZE_SIZE__ and  __NO_INLINE__,
removing the superfluous copies in the target-specific
tests, since it's target-independent.

This uncovered a bug in the handling of -Oz: it would
attempt to store the value 2 in the 1-bit bitfield OptimizeSize,
leaving a value of 0 and never defining __OPTIMIZE_SIZE__.

llvm-svn: 161495

llvm-svn: 161494

llvm-svn: 161493

llvm-svn: 161492

Committing it first as it makes the "real" patch a lot easier to read.

llvm-svn: 161491

llvm-svn: 161489