llvm-svn: 196918

Add support for more filename extensions based on the list in the clang
plus JavaScript.

Also adds a -regex option so users can override defaults if they have unusual
file extensions or want to format everything in the diff.

Keeping with tradition the flag is modelled on Unix conventions, this time
matching the semantics of find(1).

llvm-svn: 196917

llvm-svn: 196916

llvm-svn: 196915

llvm-svn: 196914

llvm-svn: 196913

Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful
option and can give surprising results (like tail calls being disabled).

5.0 seems like a reasonable compromise as a platform that's still interesting
to some people.

rdar://problem/15567348

llvm-svn: 196912

lto.exports really exports LLVM-C Disasm stuff.

llvm-svn: 196911

Summary: The result register of these instructions is also the first operand.

Reviewers: jacksprat, dsanders

Reviewed By: dsanders

Differential Revision: http://llvm-reviews.chandlerc.com/D2362
Differential Revision: http://llvm-reviews.chandlerc.com/D2363

llvm-svn: 196910

Summary:
Allow predefined styles to define different options for different
languages so that one can run:
  clang-format -style=google file1.cpp file2.js

or use a single .clang-format file with "BasedOnStyle: Google" for both c++ and
JS files.

Added Google style for JavaScript with "BreakBeforeTernaryOperators" set to
false.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

Differential Revision: http://llvm-reviews.chandlerc.com/D2364

llvm-svn: 196909

llvm-svn: 196908

llvm-svn: 196907

One unusual feature of the z architecture is that the result of a
previous load can be reused indefinitely for subsequent loads, even if
a cache-coherent store to that location is performed by another CPU.
A special serializing instruction must be used if you want to force
a load to be reattempted.

Since volatile loads are not supposed to be omitted in this way,
we should insert a serializing instruction before each such load.
The same goes for atomic loads.

The patch implements this at the IR->DAG boundary, in a similar way
to atomic fences.  It is a no-op for targets other than SystemZ.

llvm-svn: 196906

One unusual feature of the z architecture is that the result of a
previous load can be reused indefinitely for subsequent loads, even if
a cache-coherent store to that location is performed by another CPU.
A special serializing instruction must be used if you want to force
a load to be reattempted.

Since volatile loads are not supposed to be omitted in this way,
we should insert a serializing instruction before each such load.
The same goes for atomic loads.

The patch implements this at the IR->DAG boundary, in a similar way
to atomic fences.  It is a no-op for targets other than SystemZ.

llvm-svn: 196905

llvm-svn: 196904

llvm-svn: 196903

[CMake] lli/CMakeLists.txt: Move add_subdirectory(ChildTarget) to the front. It depends on nothing described in LLVM_LINK_COMPONENTS.

llvm-svn: 196902

Summary:
The rule from the GNU style states:
"We find it easier to read a program when it has spaces before the open-parentheses and after the commas."

http://www.gnu.org/prep/standards/standards.html#index-spaces-before-open_002dparen

This patch makes clang-format adds an option to put spaces before almost all open parentheses, except the cases, where different behavior is dictated by the style rules or language syntax:
  * preprocessor:
    ** function-like macro definitions can't have a space between the macro name and the parenthesis;
    ** `#if defined(...)` can have a space, but it seems, that it's more frequently used without a space in GCC, for example;
  * never add spaces after unary operators;
  * adding spaces between two opening parentheses is controlled with the `SpacesInParentheses` option;
  * never add spaces between `[` and `(` (there's no option yet).

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

Differential Revision: http://llvm-reviews.chandlerc.com/D2326

llvm-svn: 196901

[asan] remove one test from SizedStackTest which relied on a now-wrong assumption that the left stack redzone is >= 32 bytes (PR18195)

llvm-svn: 196900

llvm-svn: 196898

llvm-svn: 196897

llvm-svn: 196896

Code to create COFF section header was scattered across many member functions
of SectionChunk. Consolidate it to a member function of SectionHeaderTableChunk.

llvm-svn: 196895

llvm-svn: 196894

llvm-svn: 196893

more than one such initializer in a union, make mem-initializers override
default initializers for other union members, handle anonymous unions with
anonymous struct members better. Fix a couple of semi-related bugs exposed by
the tests for same.

llvm-svn: 196892

llvm-svn: 196891

... because they are used only in the function for relocations.

llvm-svn: 196890

  This is a small change to be strict. Just want get pattern safer.

llvm-svn: 196889

llvm-svn: 196888

llvm-svn: 196887

llvm-svn: 196884

llvm-svn: 196883

llvm-svn: 196882

I'll prune redundant deps in LLVMBuild.txt, later.

llvm-svn: 196881

llvm-svn: 196880

This reverts commit r196876.  Its tests failed on the bots, so I'll
figure it out tomorrow.

llvm-svn: 196879

Use of static is recommended by the style guide.

llvm-svn: 196877

For stack frames requiring realignment, three pointers may be needed:
- ebp to address incoming arguments
- esi (could be any callee-saved register) to address locals
- esp to address outgoing arguments

We would use esi unconditionally without verifying that it did not
conflict with inline assembly.

This change doesn't do the verification, it simply emits a fatal error
on functions that use stack realignment, dynamic SP adjustments, and
inline assembly.

Because stack realignment is common on Windows, we also no longer assume
that MS inline assembly clobbers esp.  Instead, we analyze the inline
instructions for implicit definitions and check if esp is there.  If so,
we require the use of a base pointer and consider it in the condition
above.

Mostly fixes PR16830, but we could try harder to find a non-conflicting
base pointer.

Reviewers: sunfish

Differential Revision: http://llvm-reviews.chandlerc.com/D1317

llvm-svn: 196876

it to the LLVM project through the appropriate channels.

This reverts:
r195837: "[Sanitizer] Add rudimentary support for using libbacktrace in ..."

llvm-svn: 196875