The new progress bar mode was losing us information compared to the old dots mode in that we would have no way of knowing about test failures (short of peeking into the test result directory.. and you're not supposed to peek!)

Added a new line of information that reports the count of tests that pass, fail or have other things happen to them.

Again no flag to have the dots back. If you care, let us know!

llvm-svn: 174784

This is part of the plan to delete LiveVariables.

llvm-svn: 174783

llvm-svn: 174782

Separate the checking for the missing invalidation methods into a
separate checker so that it can be turned on/off independently.

llvm-svn: 174781

llvm-svn: 174780

The new annotation allows having methods that only partially invalidate
IVars and might not be called from the invalidation methods directly
(instead, are guaranteed to be called before the invalidation occurs).
The checker is going to trust the programmer to call the partial
invalidation method before the invalidator.This is common in cases when
partial object tear down happens before the death of the object.

llvm-svn: 174779

llvm-svn: 174778

The LLDB test suite now shows a progress bar instead of dots when not in verbose mode
If you crave the dots, make your Terminal window smaller than 10 columns :-)
(or ask for a flag to have the dots come back on demand)

llvm-svn: 174777

Enables raw_ostream I/O for BasicBlockPass.

llvm-svn: 174776

"auto-synthesized may not work correctly with 'nib' loader"
when 'readonly' property is redeclared 'readwrite' in class
extension. // rdar://13123861

llvm-svn: 174775

This uses a liveness algorithm that does not depend on data from the
LiveVariables analysis, it is the first step towards removing
LiveVariables completely.

llvm-svn: 174774

check_cxx_symbol_exists requires CMake 2.8.6, so even though I
recommended it to Owen it's probably better to stay away for now.
This check is not technically correct because we're checking <math.h>
but then using <cmath> in the actual code, but if we run into problems we
can do the same sort of dance as isinf() and isnan() where we check /both/
headers and then write a wrapper header around them.

llvm-svn: 174773

to pass it to CFGetTypeID() anyway.

<rdar://problem/13181904>

llvm-svn: 174772

to use -Wfoo instead of -Wno-foo. This works around a bug in some versions of
gcc, where it will silently accept an unknown -Wno-foo option, but will
generate an error for a compile which uses -Wno-foo if that compile also
triggers any warnings.

llvm-svn: 174770

Should fix the MSC bot.

llvm-svn: 174769

Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.

llvm-svn: 174768

I threw in a couple of test cases for UD-suffixes -- already working, but
it wasn't immediately obvious to me.

llvm-svn: 174767

This may not always be valid, but we were previously just
emitting them raw.

While here, s/isprint/isPrintable/ (using the new CharInfo).

llvm-svn: 174766

Rewriting the same predicates over and over again is bad for code size and
code maintainence. Using the functions in <ctype.h> is generally unsafe
unless they are specified to be locale-independent (i.e. only isdigit and
isxdigit).

The next commit will try to clean up uses of <ctype.h> functions within Clang.

llvm-svn: 174765

llvm-svn: 174764

Also output a more useful error message.

NOTE: This is a candidate for the Mesa stable branch
llvm-svn: 174763

This fixes a couple of bugs and incorrect assumptions,
in total four more piglit tests now pass.

v2: fix small bug in the dominator updating

Patch by: Christian König

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 174762

Patch by: Christian König

Intersecting loop handling was wrong.

Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 174761

Otherwise we sometimes produce invalid code.

Patch by: Christian König

Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 174760

llvm-svn: 174759

llvm-svn: 174758

1 - A store off the end of a buffer in ValueObject.cpp
2 - DataExtractor had cases where bad offsets could cause invalid memory to be accessed.

llvm-svn: 174757

llvm-svn: 174756

Fixed a store to data that isn't needed and that also could end up writing beyond the end of the buffer. This was found by the address sanitizer.

llvm-svn: 174755

Unset the environment variables as soon as possible when running the test suite. Also don't store the unset list into a global when they aren't needed in a global variable.

llvm-svn: 174750

llvm-svn: 174749

This reverts r171041. This was a nice idea that didn't work out well.
Clang warnings need to be associated with warning groups so that they can
be selectively disabled, promoted to errors, etc. This simplistic patch didn't
allow for that. Enhancing it to provide some way for the backend to specify
a front-end warning type seems like overkill for the few uses of this, at
least for now.

llvm-svn: 174748

same so we put in the comment field an indicator when we think we are
emitting the 16 bit version. For the direct object emitter, the difference is 
important as well as for other passes which need an accurate count of 
program size. There will be other similar putbacks to this for various
instructions.

llvm-svn: 174747

Previously, even when a pre-increment load or store was generated,
we often needed to keep a copy of the original base register for use
with other offsets. If all of these offsets are constants (including
the offset which was combined into the addressing mode), then this is
clearly unnecessary. This change adjusts these other offsets to use the
new incremented address.

llvm-svn: 174746

read another one, just as we do for types.

llvm-svn: 174745

llvm-svn: 174744

This is a follow-up to the cost-model change in r174713 which splits
the cost of a memory operation between the address computation and the
actual memory access. In r174713, this cost is always added to the
memory operation cost, and so BBVectorize will do the same.

Currently, this new cost function is used only by ARM, and I don't
have any ARM test cases for BBVectorize. Assistance in generating some
good ARM test cases for BBVectorize would be greatly appreciated!

llvm-svn: 174743

llvm-svn: 174742

Aside from the question of whether we report a warning or an error when we
can't satisfy a requested stack object alignment, the current implementation
of this is not good.  We're not providing any source location in the diagnostics
and the current warning is not connected to any warning group so you can't
control it.  We could improve the source location somewhat, but we can do a
much better job if this check is implemented in the front-end, so let's do that
instead.  <rdar://problem/13127907>

llvm-svn: 174741

This updates the current references to links that work for me.
In the future, we should update the list of references itself to provide
information on newer architecture variants.

Thanks to Sean Silva for pointing out that the current links were broken!

llvm-svn: 174739