XML printer.

A test has been added that tries to comprehensively test emitting
XUnit XML output for shell tests.

Differential Revision: https://reviews.llvm.org/D45567

llvm-svn: 330409

llvm-svn: 330408

Diagnostic:
  'index must be multiple of 3 in range [-32, 28]'

Must be:
  'index must be multiple of 4 in range [-32, 28]'

llvm-svn: 330407

Summary:
This is patch [3/4] in a series to add assembler/disassembler support for
SVE's contiguous LD1 (scalar+scalar) instructions:
- Patch [1/4]: https://reviews.llvm.org/D45687
- Patch [2/4]: https://reviews.llvm.org/D45688
- Patch [3/4]: https://reviews.llvm.org/D45689
- Patch [4/4]: https://reviews.llvm.org/D45690

Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro

Reviewed By: SjoerdMeijer

Subscribers: tschuett, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D45689

llvm-svn: 330406

FileSpec class was moved to the Utility module a while ago, but the test
file was left behind. This corrects that.

llvm-svn: 330405

Summary:
Generate attribute 'denorms-are-zero'='true' if '-cl-denorms-are-zero'
compile option was specified and 'denorms-are-zero'='false' otherwise.

Patch by krisb

Reviewers: Anastasia, yaxunl

Reviewed By:  yaxunl 

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D45808

llvm-svn: 330404

Hopefully, changing set to vector removes nondeterminism detected by
some bots, or the new assert will catch something.

This reverts commit r330180.

llvm-svn: 330403

llvm-svn: 330402

Reviewers: spatel, jyknight

Reviewed By: spatel

Subscribers: fedor.sergeev, llvm-commits

Differential Revision: https://reviews.llvm.org/D45809

llvm-svn: 330401

llvm-svn: 330400

llvm-svn: 330399

llvm-svn: 330398

Summary:
Reading Atmel's AT697E errata document this does not seem like a valid
workaround. While the text only mentions SDIV, it says that the ICC flags
can be wrong, and those are only generated by SDIVcc. Verification on
hardware shows that simply replacing SDIV with SDIVcc does not avoid
the bug with negative operands.

This reverts r283727.

Reviewers: lero_chris, jyknight

Reviewed By: jyknight

Subscribers: fedor.sergeev, jrtc27, llvm-commits

Differential Revision: https://reviews.llvm.org/D45813

llvm-svn: 330397

Using `clr reg`/`mov %g0, reg`/`or %g0, %g0, reg` to zero a register
looks much better than `sethi 0, reg`.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

Subscribers: eraman, fedor.sergeev, jrtc27, llvm-commits

Differential Revision: https://reviews.llvm.org/D45810

llvm-svn: 330396

This broke the Windows build, see e.g. http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10130

> Differential Revision: https://reviews.llvm.org/D44246

llvm-svn: 330395

Summary:
In some cases the shift/extend needs to be explicitly parsed together
with the register, rather than as a separate operand. This is needed
for addressing modes where the instruction as a whole dictates the
scaling/extend, rather than specific bits in the instruction.
By parsing them as a single operand, we avoid the need to pass an
extra operand in all CodeGen patterns (because all operands need to
have an associated value), and we avoid the need to update TableGen to
accept operands that have no associated bits in the instruction.

An added benefit of parsing them together is that the assembler
can give a sensible diagnostic if the scaling is not correct.

This is patch [2/4] in a series to add assembler/disassembler support for
SVE's contiguous LD1 (scalar+scalar) instructions:
- Patch [1/4]: https://reviews.llvm.org/D45687
- Patch [2/4]: https://reviews.llvm.org/D45688
- Patch [3/4]: https://reviews.llvm.org/D45689
- Patch [4/4]: https://reviews.llvm.org/D45690

Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro

Reviewed By: fhahn, SjoerdMeijer

Subscribers: kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D45688

llvm-svn: 330394

Summary:
This fixes a case where the argument to a sendmsg intrinsic
ends up in a VGPR, for whatever reason.

The underlying performance issue is that a multiplication that
can be an s_mul_i32 is instead needlessly generated as
v_mul_u32_u24, but this is not addressed by this patch.

Change-Id: I61fd4034314d5acdf6074632c30b65364dfa7328

Reviewers: arsenm, rampitec

Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

Differential Revision: https://reviews.llvm.org/D45826

llvm-svn: 330393

Summary:
If a 64-bit register is used as an operand in inline assembly together
with a memory reference, the memory addressing will be wrong. The
addressing will be a single reg, instead of reg+reg or reg+imm. This
will generate a bad offset value or an exception in printMemOperand().

For example:

```
long long int val = 5;
long long int mem;
__asm__ volatile ("std %1, %0":"=m"(mem):"r"(val));
```
becomes:

```
std %i0, [%i2+589833]
```

The problem is that SelectInlineAsmMemoryOperand() is never called for
the memory references if one of the operands is a 64-bit register.
By calling SelectInlineAsmMemoryOperands() in tryInlineAsm() the Sparc
version of  SelectInlineAsmMemoryOperand() gets called for each memory
reference.

Reviewers: jyknight, venkatra

Reviewed By: jyknight

Subscribers: eraman, fedor.sergeev, jrtc27, llvm-commits

Differential Revision: https://reviews.llvm.org/D45761

llvm-svn: 330392

This upstreams a feature from the JFS solver's fork of LibFuzzer.

Differential Revision: https://reviews.llvm.org/D45675

llvm-svn: 330391

This test is failing on my Linux box. Just increasing the number of
iterations works around this. The divergence is likely due to
our reliance on `std::shuffle()` which is not guaranteed to have
the same behaviour across platforms.

This is a strong argument for us to implement our own shuffle
function to avoid divergence in behaviour across platforms.

Differential Revision: https://reviews.llvm.org/D45767

llvm-svn: 330390

The `unbalanced_allocs.py` script uses Python 2 print statement
and `iteritems()`. Running `2to3` over the script fixes these.

Differential Revision: https://reviews.llvm.org/D45765

llvm-svn: 330389

llvm-svn: 330388

Summary:
This change fixes https://crbug.com/834474, a build failure caused by
LowerTypeTests not preserving .symver symbol versioning directives for
exported functions. Emit symver information to ThinLTO summary data and
then propagate symver directives for exported functions to the merged
module.

Emitting symver information to the summaries increases the size of
intermediate build artifacts for a Chromium build by less than 0.2%.

Reviewers: pcc

Reviewed By: pcc

Subscribers: tejohnson, mehdi_amini, eraman, llvm-commits, eugenis, kcc

Differential Revision: https://reviews.llvm.org/D45798

llvm-svn: 330387

The test was passing on a big endian host, but just because od with x4
was compensating for it.

llvm-svn: 330386

llvm-svn: 330385

Fixes some link issues.

llvm-svn: 330384

This is needed for fd_set.

Differential Revision: https://reviews.llvm.org/D45852

llvm-svn: 330383

Loop condition variables, eg.

  while (shared_ptr<int> P = getIntPtr()) { ... })

weren't handled in r324794 because they don't go through the common
CFGBuilder::VisitDeclStmt method. Which means that they regressed
after r324800.

Fix the regression by duplicating the necessary construction context scan in
the loop visiting code.

Differential Revision: https://reviews.llvm.org/D45706

llvm-svn: 330382

If a pointer cast fails (evaluates to an UnknownVal, i.e. not implemented in the
analyzer) and such cast is in fact the last use of the pointer, the pointer
symbol is no longer referenced by the program state and a leak is
(mis-)diagnosed.

"Escape" the pointer upon a failed cast, i.e. inform the checker that we can no
longer reliably track it.

Differential Revision: https://reviews.llvm.org/D45698

llvm-svn: 330380

Reviewers: ruiu, espindola

Subscribers: emaste, arichardson, llvm-commits

Differential Revision: https://reviews.llvm.org/D45846

llvm-svn: 330379

This implements support for the previously ignored flag
`-falign-functions`.  This allows the frontend to request alignment on
function definitions in the translation unit where they are not
explicitly requested in code.  This is compatible with the GCC behaviour
and the ICC behaviour.

The scalar value passed to `-falign-functions` aligns functions to a
power-of-two boundary.  If flag is used, the functions are aligned to
16-byte boundaries.  If the scalar is specified, it must be an integer
less than or equal to 4096.  If the value is not a power-of-two, the
driver will round it up to the nearest power of two.

llvm-svn: 330378

Function argument constructors (that are used for passing objects into functions
by value) are completely unlike temporary object constructors, but we were
treating them as such because they are also wrapped into a CXXBindTemporaryExpr.

This patch adds a partial construction context layer for call argument values,
but doesn't proceed to transform it into an actual construction context yet.
This is tells the clients that we aren't supporting these constructors yet.

Differential Revision: https://reviews.llvm.org/D45650

llvm-svn: 330377

Differential Revision: https://reviews.llvm.org/D44246

llvm-svn: 330376

r315736 added support for the misplaced CF_RETURNS_RETAINED annotation on
CFRetain() wrappers. It works by trusting the function's name (seeing if it
confirms to the CoreFoundation naming convention) rather than the annotation.

There are more false positives caused by users using a different naming
convention, namely starting the function name with "retain" or "release"
rather than suffixing it with "retain" or "release" respectively.

Because this isn't according to the naming convention, these functions
are usually inlined and the annotation is therefore ignored, which is correct.
But sometimes we run out of inlining stack depth and the function is
evaluated conservatively and then the annotation is trusted.

Add support for the "alternative" naming convention and test the situation when
we're running out of inlining stack depth.

rdar://problem/18270122

Differential Revision: https://reviews.llvm.org/D45117

llvm-svn: 330375

Relocation addends can be negative so should be written as
signed LEBs. This bug meant that writing value between 64
and 128 would be incorrectly interpreted as negative by the
object file readers.

Differential Revision: https://reviews.llvm.org/D45825

llvm-svn: 330374

This moves the EnableLinkOnceODROutlining flag from TargetPassConfig.cpp into
MachineOutliner.cpp. It also removes OutlineFromLinkOnceODRs from the
MachineOutliner constructor. This is now handled by the moved command-line
flag.

llvm-svn: 330373

Reviewers: EricWF, pcc

Subscribers: christof, cfe-commits

Differential Revision: https://reviews.llvm.org/D45836

llvm-svn: 330372

llvm-svn: 330371

This is a temporary solution until a proper WASM implementation of
MCAsmParserExtension is in place, but at least for now will unblock this
path.

Added test to make sure this path works with the WASM Assembler.

Patch By Wouter van Oortmerssen!

Differential Revision: https://reviews.llvm.org/D45386

llvm-svn: 330370

We have relatively few tests on the contents of non alloc
sections. This one would have found a bug in a patch I am working on.

llvm-svn: 330369