extern "C", its method definitions must be IRGen'ed
before meta-data for class is generated. Otherwise,
IRGen crashes (to say the least).
// rdar://12581683 

llvm-svn: 166809

is absolute.

llvm-svn: 166808

varargs parameter passing.

A strict reading of the ABI indicates that any argument with alignment greater
than 8 may require skipping doublewords in the parameter save area to align
the argument, and hence require skipping GPRs.  In practice, this is not done
by GCC.  The alignment restriction is used for internal alignment of a
structure, but a structure with 16-byte alignment, for example, is not
itself 16-byte aligned in the parameter save area.  Although this is messy,
it has become the de facto standard used in building existing libraries.

My initial varargs support followed the ABI language, but not the de facto
standard.  Running the GCC compatibility test suite exposed this issue, and
indeed showed that LLVM didn't pass parameters self-consistently with my
original logic.  Removing the additional alignment logic allows the affected
tests to now pass.

I modified the ppc64-varargs-struct.c test case to remove the existing test
for generation of alignment code, which is no longer appropriate.

Built and tested on powerpc64-unknown-linux-gnu with no new regressions.

llvm-svn: 166805

llvm-svn: 166804

APInt::shl generated llvm.trap to guard against shifts greater than bit-width.
This was already checked with an assert, and there was a special case for
shifts equal to bit-width. Modify this check to catch shifts greater than or
equal to bit-width, so llvm.trap isn't generated.

Patch contributed by JF Bastien

llvm-svn: 166803

llvm-svn: 166802

llvm-svn: 166801

This patch updates comments in the Predicate class to describe a subtle behavior that callers may need to be aware.  It also adds documentation for one function which didn’t have any.

The subtle behavior is that the Predicate wait functions may not detect transitory changes in the predicate value.  Consider the following scenario.

Thread A waits for a bit to be set in the predicate value.
Thread B sets the bit in the predicate value.
Before Thread A wakes up, Thread C clears the bit in the predicate value.
Thread A wakes, checks the value and goes back to waiting.

The mutex and condition variables protect access to the value, but they offer no guarantee that another thread will not acquire the mutex and change the value before a waiting thread is restarted after a change.

I believe that the current behavior is correct and reasonable.  I just want to leave a marker to prevent possible problems in the future or to help anyone who might be unfortunate enough to encounter such a problem.

llvm-svn: 166800

llvm-svn: 166799

unprintable.

llvm-svn: 166798

Move the target-specific tests, which require specific backends, to dirs that only run if the target is present.

llvm-svn: 166796

list of externals. This makes sense since a shared library with no symbols
can still be useful if it has static constructors.

llvm-svn: 166795

llvm-svn: 166794

llvm-svn: 166793

Part of rdar://12576868

llvm-svn: 166792

llvm-svn: 166791

Part of rdar://12576868

llvm-svn: 166790

Updated the "breakpoint command add" documentation and fixed the web site docs for the signature of the python breakpoint callback functions.

llvm-svn: 166789

This is currently true, but may change when DA grows more aggressive caching.
Without this setting it's impossible to use DA from a LoopPass because DA is a
function pass and cannot be properly scheduled in between LoopPasses. The
LoopManager reacts to this with an infinite loop which made this really annoying
to debug.

llvm-svn: 166788

The LoopSimplify bug is pretty harmless because the loop goes from unanalyzable
to analyzable but the LCSSA bug is very nasty. It only comes into play with a
specific order of the LoopPassManager worklist and can cause actual
miscompilations, when a SCEV refers to a value that has been replaced with PHI
node. SCEVExpander may then insert code into the wrong place, either violating
domination or randomly miscompiling stuff.

Comes with an extensive test case reduced from the test-suite with
bugpoint+SCEVValidator.

llvm-svn: 166787

Enabled with -verify-scev. This could be extended significantly but hopefully
catches the common cases now. Note that it's not enabled by default in any
configuration because the way it tries to distinguish SCEVs is still fragile and
may produce false positives. Also the test-suite isn't clean yet, one example
is that it fails if a pass drops an NSW bit but it's still present in SCEV's
cached. Cleaning up all those cases will take some time.

llvm-svn: 166786

PR14183.

llvm-svn: 166785

llvm-svn: 166784

only actually get the answer right if there was only a single
anonymous struct/union at that level. This is part of
<rdar://problem/11904570>; the test will go into LLDB itself.

llvm-svn: 166781

llvm-svn: 166780

operator.

llvm-svn: 166779

llvm-svn: 166778

ASTImporter.

llvm-svn: 166777

allowed to complain about a failure.

llvm-svn: 166776

llvm-svn: 166775

llvm-svn: 166774

Patch by Pasi Parviainen <pasi.parviainen@iki.fi>

llvm-svn: 166773

llvm-svn: 166772

llvm-svn: 166771

This patch fixes the rldcl/rldicl/rldicr instruction emission. The issue is
the MDForm_1 instruction defines the PowerISA MB field from 'rldicl'
with the name MBE, but RLDCL/RLDICL/RLDICR definition uses as 'MB'.

It end up by generatint the 'rldicl' enconding at 
'lib/Target/PowerPC/PPCGenMCCodeEmitter.inc' to use the fourth argument as the
third. The patch changes it by adjusting to use the fourth argument as
intended.

Fixes PR14180.

llvm-svn: 166770

llvm-svn: 166769

This may result in a crash at startup.
Fixes http://code.google.com/p/address-sanitizer/issues/detail?id=123.

llvm-svn: 166768

Always use an exit code of 1, but print the help message if useful.
Remove the exception handling tag in llvm-as, llvm-dis and
llvm-bcanalyzer, where it isn't used.

llvm-svn: 166767

separate tool.

Review: http://llvm-reviews.chandlerc.com/D81
llvm-svn: 166766

Patch by Joey Gouly.

llvm-svn: 166765