Summary:
In https://bugs.freebsd.org/207918, Daniel McRobb describes how using
std::showbase with ostreams can cause truncation of unsigned long long
when output format is octal.  In fact, this can even happen with
unsigned int and unsigned long.

To ensure this does not happen, add one additional character to the
do_put buffers if std::showbase is on.  Also add a test case.

Reviewers: EricWF, mclow.lists

Reviewed By: EricWF

Subscribers: cfe-commits, emaste

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

llvm-svn: 302362

llvm-svn: 302361

llvm-svn: 302360

Extend NoVLX targets to use the 512-bit versions

llvm-svn: 302359

This test was introduced in r302339. It works on my system, but breaks on the
buildbots.

llvm-svn: 302358

[X86] Reduce code for setting operations actions by merging into loops across multiple types/ops. NFCI.

llvm-svn: 302357

Use the ISD::ABS opcode directly

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

llvm-svn: 302356

rL294581 broke unnecessary register dependencies on partial v16i8/v8i16 BUILD_VECTORs, but on SSE41 we (currently) use insertion for full BUILD_VECTORs as well. By allowing full insertion to occur on SSE41 targets we can break register dependencies here as well.

llvm-svn: 302355

Summary:
When writing a loop pass I made a mistake and hit the assertion
"Unreachable block in loop". Later, I hit an assertion when I called
`BasicBlock::eraseFromParent()` incorrectly: "Use still stuck around
after Def is destroyed". This latter assertion, however, printed out
exactly which value is being deleted and what uses remain, which helped
me debug the issue.

To help people debugging their loop passes in the future, print out
exactly which basic block is unreachable in a loop.

Reviewers: sanjoy, hfinkel, mehdi_amini

Reviewed By: mehdi_amini

Subscribers: mzolotukhin

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

llvm-svn: 302354

Enabled emulated TLS on WOA for mingw
Fix <windows.h> include for mingw

Reviewed By: chapuni, mstorsjo

Subscribers: compnerd, llvm-commits

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

llvm-svn: 302340

Extend the Knowledge class to store information about the contents
of array elements and which values are written. Two knowledges do
not conflict the known content is the same. The content information
if computed from writes to and loads from the array elements, and
represented by "ValInst": isl spaces that compare equal if the value
represented is the same.

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

llvm-svn: 302339

Many more to come...

llvm-svn: 302338

Remove an extra canonicalization step if ISD::ABS is going to be used anyway.

Updated x86 abs combine to check that we are lowering from both canonicalizations.

llvm-svn: 302337

Allow using a system's install jsoncpp library instead of the bundled
one with the setting POLLY_BUNDLED_JSONCPP=OFF.

This fixes llvm.org/PR32929

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

llvm-svn: 302336

This changes one parameter to be a const APInt& since we only read from it. Use std::move on local APInts once they are no longer needed so we can reuse their allocations. Lastly, use operator+=(uint64_t) instead of adding 1 to an APInt twice creating a new APInt each time.

llvm-svn: 302335

llvm-svn: 302334

llvm-svn: 302333

llvm-svn: 302332

Summary:
ConstantRange contains two APInts which can allocate memory if their width is larger than 64-bits. So we shouldn't copy it when we can avoid it.

This changes LVILatticeVal::getConstantRange() to return its internal ConstantRange by reference. This allows many places that just need a ConstantRange reference to avoid making a copy.

Several places now capture the return value of getConstantRange() by reference so they can call methods on it that don't need a new object.

Lastly it adds std::move in one place to capture to move a local ConstantRange into an LVILatticeVal.

Reviewers: reames, dberlin, sanjoy, anna

Reviewed By: reames

Subscribers: grandinj, llvm-commits

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

llvm-svn: 302331

llvm-svn: 302330

Recreated patch for __NetBSD__ has been pushed upstream to Google.

llvm-svn: 302329

If we can't find the "is dyld locked" symbol, assume it is safe
to load the image unless we only have 1 image loaded - in which case
we are in _dyld_start and it is definitely NOT safe.

Also add a little better errors to that function, and better logging
in SBProcess.cpp.

<rdar://problem/30174817>

llvm-svn: 302327

This patch do s/color/class/g.

llvm-svn: 302326

Fixes D32926.

llvm-svn: 302325

llvm-svn: 302324

llvm-svn: 302323

The expressions `1 == 1` and `true` have the same type, value category, and value.

Fixes D32924.

llvm-svn: 302322

[sanitizer-coverage] implement -fsanitize-coverage=no-prune,... instead of a hidden -mllvm flag. compiler-rt part (test only).

llvm-svn: 302321

[sanitizer-coverage] implement -fsanitize-coverage=no-prune,... instead of a hidden -mllvm flag. clang part.

llvm-svn: 302320

[sanitizer-coverage] implement -fsanitize-coverage=no-prune,... instead of a hidden -mllvm flag. llvm part.

llvm-svn: 302319

In C++17, these iterators are allowed but not required
to inherit from the deprecated std::iterator base class.

Fixes D32727.

llvm-svn: 302318

Summary: Use the cxxStdInitializerListExp matcher from ASTMatchers.h instead of a local one.

Reviewers: aaron.ballman, alexfh, Prazek

Reviewed By: aaron.ballman

Subscribers: xazax.hun, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 302317

This is a step toward having statically allocated instruciton mapping.
We are going to tablegen them eventually, so let us reflect that in
the API.

NFC.

llvm-svn: 302316

[BitVector] Improve the description of the BitVector::clear to say it removes the bits rather than clearing since clearing could be interpreted as just zeroing. NFC

llvm-svn: 302315

These methods can be used by the derived expression types to perform expression
specific and/or language specific actions before and after the expression runs.
(ThreadPlanCallUserExpression is modified to call these methods on the
expression immediately before/after execution of the expression).

The immediate motivation is allowing Swift expressions to notify the swift
runtime that exclusivity enforcement should be suspended while the expression
runs (we want LLDB expressions to be able to access variables even when they're
considered exclusively owned by someone else in the original program).

Reviewed in https://reviews.llvm.org/D32889

llvm-svn: 302314

It turns out there are some sort-of-but-not-quite empty structs that break all
the rules. For example:

struct SuperEmpty { int arr[0]; };
struct SortOfEmpty { struct SuperEmpty e; };

Both of these have sizeof == 0, even in C++ mode, for GCC compatibility. The
first one also doesn't occupy a register when passed by value in GNU C++ mode,
unlike everything else.

On Darwin, we want to ignore the lot (and especially don't want to try to use
an i0 as we were).

llvm-svn: 302313

This is necessary to be able to build a libc++ module from preprocessed source
(due to the submodule std.new).

llvm-svn: 302312

llvm-svn: 302311

llvm-svn: 302310

To support this, an optional marker "#pragma clang module contents" is
recognized in module map files, and the rest of the module map file from that
point onwards is treated as the source of the module. Preprocessing a module
map produces the input module followed by the marker and then the preprocessed
contents of the module.

Ignoring line markers, a preprocessed module might look like this:

  module A {
    header "a.h"
  }
  #pragma clang module contents
  #pragma clang module begin A
  // ... a.h ...
  #pragma clang module end

The preprocessed output generates line markers, which are not accepted by the
module map parser, so -x c++-module-map-cpp-output should be used to compile
such outputs.

A couple of major parts do not work yet:

1) The files that are listed in the module map must exist on disk, in order to
   build the on-disk header -> module lookup table in the PCM file. To fix
   this, we need the preprocessed output to track the file size and other stat
   information we might use to build the lookup table.

2) Declaration ownership semantics don't work properly yet, since mapping from
   a source location to a module relies on mapping from FileIDs to modules,
   which we can't do if module transitions can occur in the middle of a file.

llvm-svn: 302309