llvm-svn: 181911

We want the order to be deterministic on all platforms. NAKAMURA Takumi
fixed that in r181864. This patch is just two small cleanups:

* Move the function to the cpp file. It is only passed to array_pod_sort.
* Remove the ppc implementation which is now redundant

llvm-svn: 181910

DefaultBool is basically just "bool with a default constructor", so it
really should implicitly convert to bool. In fact, it should convert to
bool&, so that it could be passed to functions that take bools by reference.

This time, mark the operator bool& as implicit to promise that it's
deliberate.

llvm-svn: 181908

llvm-svn: 181907

llvm-svn: 181906

- "platform process list" command works on Linux now
- "process attach -n" (attach to process by name also works on Linux now)

llvm-svn: 181905

- read process information from /proc
- resolves llvm.org/pr14541 :)

Patch by Mike Sartain!

llvm-svn: 181904

Revert r181833: lldb prompt issue still occurs on buildbot (http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/4124)
- maybe consider checking in the 'good' version of libedit to avoid ancient system version

llvm-svn: 181903

- filed llvm.org/pr16016
- fixed URL for llvm.org/pr16000

llvm-svn: 181902

[objc-arc] Fixed a spelling error and made the statistic descriptions be consistent about their usage of periods.

llvm-svn: 181901

llvm-svn: 181900

- newlines from GetRepositoryPath output were interfering with ninja builds
- replace newlines with spaces
- remove *only* trailing spaces from repo path

llvm-svn: 181899

This patch matches GCC behavior: the code used to only allow unaligned
load/store on ARM for v6+ Darwin, it will now allow unaligned load/store for
v6+ Darwin as well as for v7+ on other targets.

The distinction is made because v6 doesn't guarantee support (but LLVM assumes
that Apple controls hardware+kernel and therefore have conformant v6 CPUs),
whereas v7 does provide this guarantee (and Linux behaves sanely).

Overall this should slightly improve performance in most cases because of
reduced I$ pressure.

Patch by JF Bastien

llvm-svn: 181897

patch (r181847).

llvm-svn: 181896

Remove MCELFObjectTargetWriter::adjustFixupOffset hack

Now that PowerPC no longer uses adjustFixupOffset, and no other
back-end (ever?) did, we can remove the infrastructure itself
(incidentally addressing a FIXME to that effect).

llvm-svn: 181895

[PowerPC] Remove need for adjustFixupOffst hack

Now that applyFixup understands differently-sized fixups, we can define
fixup_ppc_lo16/fixup_ppc_lo16_ds/fixup_ppc_ha16 to properly be 2-byte
fixups, applied at an offset of 2 relative to the start of the 
instruction text.

This has the benefit that if we actually need to generate a real
relocation record, its address will come out correctly automatically,
without having to fiddle with the offset in adjustFixupOffset.

Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.

llvm-svn: 181894

Thanks to Ulrich Weigand for noticing that this instruction was missing.

llvm-svn: 181893

[PowerPC] Add test case for r181891

llvm-svn: 181892

[PowerPC] Correctly handle fixups of other than 4 byte size

The PPCAsmBackend::applyFixup routine handles the case where a
fixup can be resolved within the same object file.  However,
this routine is currently hard-coded to assume the size of
any fixup is always exactly 4 bytes.

This is sort-of correct for fixups on instruction text; even
though it only works because several of what really would be
2-byte fixups are presented as 4-byte fixups instead (requiring
another hack in PPCELFObjectWriter::adjustFixupOffset to clean
it up).

However, this assumption breaks down completely for fixups
on data, which legitimately can be of any size (1, 2, 4, or 8).

This patch makes applyFixup aware of fixups of varying sizes,
introducing a new helper routine getFixupKindNumBytes (along
the lines of what the ARM back end does).  Note that in order
to handle fixups of size 8, we also need to fix the return type
of adjustFixupValue to uint64_t to avoid truncation.

Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.

llvm-svn: 181891

llvm-svn: 181890

llvm-svn: 181888

Before:
namespace abc { class SomeClass; }
namespace def { void someFunction() {} }

After:
namespace abc {
class Def;
}
namespace def {
void someFunction() {}
}

Rationale:
a) Having anything other than forward declaration on the same line
   as a namespace looks confusing.
b) Formatting namespace-forward-declaration-combinations different
   from other stuff is inconsistent.
c) Wasting vertical space close to such forward declarations really
   does not affect readability.

llvm-svn: 181887

Patch by: Antoine Lorence <Antoine.Lorence@insa-rennes.fr>

llvm-svn: 181886

llvm-svn: 181885

In the long run, this will probably be better fixed by a proper
expression parser..

Before:
  template <typename F>
  Matcher(const Matcher<F> & Other,
          typename enable_if_c < is_base_of<F, T>::value &&
              !is_same<F, T>::value > ::type * = 0)
      : Implementation(new ImplicitCastMatcher<F>(Other)) {}

After:
  template <typename F>
  Matcher(const Matcher<F> & Other,
          typename enable_if_c<is_base_of<F, T>::value &&
                               !is_same<F, T>::value>::type * = 0)
      : Implementation(new ImplicitCastMatcher<F>(Other)) {}

llvm-svn: 181884

Based on an analysis by Ulrich Weigand.

llvm-svn: 181882

llvm-svn: 181881

This commit improves Clang's diagnostics for string initialization.
Where it would previously say:

  /tmp/a.c:3:9: error: array initializer must be an initializer list
  wchar_t s[] = "Hi";
          ^
  /tmp/a.c:4:6: error: array initializer must be an initializer list or string literal
  char t[] = L"Hi";
       ^

It will now say

  /tmp/a.c:3:9: error: initializing wide char array with non-wide string literal
  wchar_t s[] = "Hi";
          ^
  /tmp/a.c:4:6: error: initializing char array with wide string literal
  char t[] = L"Hi";
       ^

As a bonus, it also fixes the fact that Clang would previously reject
this valid C11 code:

  char16_t s[] = u"hi";
  char32_t t[] = U"hi";

because it would only recognize the built-in types for char16_t and
char32_t, which do not exist in C.

llvm-svn: 181880

llvm-svn: 181879

llvm-svn: 181878

Before:
template <typename A>
SomeLoooooooooooooooooooooongType<
    typename some_namespace::SomeOtherType<A>::Type> Function() {}

After:
template <typename A>
SomeLoooooooooooooooooooooongType<
    typename some_namespace::SomeOtherType<A>::Type>
Function() {}

llvm-svn: 181877

llvm-svn: 181876

llvm-svn: 181873

llvm-svn: 181872

We only ever implemented one and that one is not actually all that
helpful (e.g. gets incorrectly triggered by macros).

llvm-svn: 181871

The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.

Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After:  #define DEREF_AND_CALL_F(parameter) f(*parameter)
llvm-svn: 181870

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.

One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).

llvm-svn: 181869

BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.

This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.

llvm-svn: 181868

It's an LP64 platform.

llvm-svn: 181867

Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated
Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing:
a) the SWIG wrapper was not checking the return value of the script
b) when passing a Python function by name, the call statement was dropping the return value of the function
This checkin addresses both concerns and makes this work
Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop!

llvm-svn: 181866