llvm-svn: 222008

If this workaround gets the bots green, then we have to find out
why the -dwarf-accel-tables=Enable option doesn't work as
expected on non-darwin platforms.

llvm-svn: 222007

Prior to this commit fmul and fadd binary operators were being canonicalized for
both scalar and vector versions.  We now canonicalize add, mul, and, or, and xor
vector instructions.

llvm-svn: 222006

llvm-svn: 222005

Apply SOCK_CLOEXEC flag to socket API functions in order to avoid handle leakage to a forked child process.

http://reviews.llvm.org/D6204

llvm-svn: 222004

This reverts commit r221842 which was a revert of r221836 and of the
test parts of r221837.

This new version fixes an UB bug pointed out by David (along with
addressing some other review comments), makes some dumping more
resilient to broken input data and forces the accelerator tables
to be dumped in the tests where we use them (this decision is
platform specific otherwise).

llvm-svn: 222003

llvm-svn: 222002

Summary:
AsanOnSIGSEGV has some heuristics for detecting stack overflow, but
they don't cope with a PowerPC store-with-update instruction which
modifies sp and stores to the modified address in one instruction.

This patch adds some PowerPC-specific code to check for this case.

This fixes the last few cases of the stack-overflow test.

Reviewers: kcc, samsonov, eugenis

Reviewed By: eugenis

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D6253

llvm-svn: 222001

This better explains a change in r221520.

llvm-svn: 222000

llvm-svn: 221999

llvm-svn: 221998

llvm-svn: 221997

llvm-svn: 221996

llvm-svn: 221995

This was done using the Sparc and PowerPC AsmParsers as guides.  So far it
is very simple and only supports sopp instructions.

llvm-svn: 221994

llvm-svn: 221993

llvm-svn: 221992

Complete support for the SD-6 standing document (based off N4200) with support for __has_cpp_attribute.

llvm-svn: 221991

With it, it prints the file being formatted. Apparently people are
formatting thousands of files and some progress indication is helpful.

llvm-svn: 221990

Before:
  void SomeLoooooooooooongFunction(
      std::unique_ptr<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa>
          aaaaaaaaaaaaaaaaaaaaaaaaaa, int bbbbbbbbbbbbb);

After:
  void SomeLoooooooooooongFunction(
      std::unique_ptr<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa>
          aaaaaaaaaaaaaaaaaaaaaaaaaa,
      int bbbbbbbbbbbbb);

llvm-svn: 221989

VSX makes the "vector long long" and "vector double" types available.
This patch enables the vec_perm interface for these types.  The same
builtin is generated regardless of the specified type, so no
additional work or testing is needed in the back end.  Tests are added
to ensure this builtin is generated by the front end.

llvm-svn: 221988

Before:
  return a != b
             // comment
             ? a
             : a = a != b
                   // comment
         ? a =
               b : a;
After:
  return a != b
             // comment
             ? a
             : a = a != b
                       // comment
                       ? a = b
                       : a;

llvm-svn: 221987

This code is not part of ASan runtime (as it may be linked into a different
DSO), and thus can not call non-exported functions.

llvm-svn: 221986

Before:
  int i = (a)
              // comment
          + b;
  return aaaa == bbbb
                 // comment
             ? aaaa
             : bbbb;
After:
  int i = (a)
          // comment
          + b;
  return aaaa == bbbb
             // comment
             ? aaaa
             : bbbb;

llvm-svn: 221985

This patch adds builtin support for xvdivdp and xvdivsp, along with a
new test case.  The builtins are accessed using vec_div in altivec.h.
Builtins are listed (mostly) alphabetically there, so inserting these
changed the line numbers for deprecation warnings tested in
test/Headers/altivec-intrin.c.

There is a companion patch for LLVM.

llvm-svn: 221984

This patch adds builtin support for xvdivdp and xvdivsp, along with a
test case.  Straightforward stuff.

There's a companion patch for Clang.

llvm-svn: 221983

llvm-svn: 221982

Change breaking preferences:
1. Break before "extends"
2. Break before "implements"
3. Break within the implements list.

llvm-svn: 221981

Summary: Something like "core:1" would match and try to be interpreted by the following code otherwise.

Test Plan: Run tests and make sure the ones failing previously now pass.

Reviewers: tfiala, clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D6257

llvm-svn: 221980

Before:
  public<R> ArrayList<R> get() {

After:
  public <R> ArrayList<R> get() {

llvm-svn: 221979

Before:
  someObject.and ();

After:
  someObject.and();

llvm-svn: 221978

r221975 seemed to trigger an ambiguous conversion that only irritated
clang, not gcc.

llvm-svn: 221977

Before:
  Function < F, ? extends T > function;

After:
  Function<F, ? extends T> function;

llvm-svn: 221976

In support of serializing executables, obj2yaml now records the virtual address
and size of sections.  It also serializes whatever we strictly need from
the PE header, it expects that it can reconstitute everything else via
inference.

yaml2obj can reconstitute a fully linked executable.

In order to get executables correctly serialized/deserialized, other
bugs were fixed as a circumstance.  We now properly respect file and
section alignments.  We also avoid writing out string tables unless they
are strictly necessary.

llvm-svn: 221975

llvm-svn: 221974

This matches std::vector and is more efficient as it avoids
truncations.

With this the text segment of opt goes from 19705442 bytes
to 19703930 bytes.

llvm-svn: 221973

The dynamic section was not aligned properly. The alignment of the section is
determined by the word size of the architecture.

llvm-svn: 221972

SearchForAddressOfSymbol(): Disable 3 symbols, copysignf, fminf, and fmaxf, on msc17. *These were added in VS 2013*

llvm-svn: 221971

Currently there is a bug in processing of global variables used as loop control variables in 'omp for/simd' constructs: these globals must be captured as private variables, but currently they are nor. This is a temporary bug fix for this problem until the correct solution is prepared. If a global var used as lcv without explicit mark as a private/linear/lastprivate the error message is emitted.

llvm-svn: 221970

The test is split such that:
- max_size.pass.cpp tests that string::resize() fails to allocator for max_size
  and max_size -1
- over_max_size.pass.cpp tests that string::resize() throws a length error for
  max_size + 1

The test was split into two because max_size.pass.cpp cannot pass with 
sanitizers but over_max_size.pass.cpp can.

llvm-svn: 221969