llvm-svn: 314373

Refactor MacroArgs to use TrailingObjects when creating a variably sized object on the heap to store the unexpanded tokens immediately after the MacroArgs object.

llvm-svn: 314372

particular causes lldb to die on startup if you have a ~/.lldbinit file.

I filed:

https://bugs.llvm.org/show_bug.cgi?id=34758

to cover fixing the bug.

llvm-svn: 314371

This fixes a bug where clang would emit instructions to reclaim a value
that's going to be __bridge-casted to CF.

rdar://problem/34687542

llvm-svn: 314370

Summary:
Link everything, including the C++ bits, in the single
ubsan_standalone SHARED library. This matches ASan setup.

Reviewers: vitalybuka

Subscribers: kubamracek, llvm-commits, mgorny

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

llvm-svn: 314369

If we do not initialize Prefix here, Prefix.data() returns a nullptr.
Later, it is passed to memcpy. memcpy's behavior is undefined if src (or
dst) is a nullptr even if a given size is 0. That's why this code
triggered UBsan.

llvm-svn: 314368

llvm-svn: 314367

assume git-style diffs.  Committing for Francis Ricci.

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

llvm-svn: 314366

compunit's .data section. This vector is not poisoned. Because of this the
first symbol of the following section has no left red zone. As a result, ASan
cannot detect underflow for such symbols.

Poison ASan allocated metadata, it should not be accessible to user code.

This fix does not eliminate the problem with missing left red zones but it
reduces the set of vulnerable symbols from first symbols in each input data
section to first symbols in the output section of the binary.

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

llvm-svn: 314365

Patch by Zbigniew Sarbinowski!

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

llvm-svn: 314364

[CodeGen] Fix some Clang-tidy modernize-use-default-member-init and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 314363

Summary:
This avoids C++ UB if the GEP is weird and the calculation overflows
int64_t, and it's also observable in the cost model's results.

Such GEPs are almost surely not valid pointers, but LLVM nonetheless
generates them sometimes.

Reviewers: sanjoy

Subscribers: llvm-commits

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

llvm-svn: 314362

This patch produces a crash and hexagon_vector_loop_carried_reuse_constant.ll test fails on Windows (llvm-clang-x86_64-expensive-checks-win build bot).

llvm-svn: 314361

Revert r314017 '[InstCombine] Simplify check for RHS being a splat constant in foldICmpUsingKnownBits by just checking Op1Min==Op1Max rather than going through m_APInt.'

This reverts r314017 and similar code added in later commits. It seems to not work for pointer compares and is causing a bot failure for the last several days.

llvm-svn: 314360

AVR32 is an unrelated architecture with 32-bit addressing.

llvm-svn: 314359

running watchos.  These tests cannot run on normal customer devices,
but I hope to some day have a public facing bot running against a
device.

llvm-svn: 314355

The data layout was changed in r314179 to fix atomic loads and stores.

llvm-svn: 314354

llvm-svn: 314353

I will use this in a later change.

llvm-svn: 314352

I will use this refactoring in a later patch.

llvm-svn: 314351

A "Result" suffix is more appropriate here

llvm-svn: 314350

The tar format originally supported up to 99 byte filename. The two
extensions are proposed later: Ustar or PAX.

In the UStar extension, a pathanme is split at a '/' and its "prefix"
and "suffix" are stored in different locations in the tar header. Since
"prefix" can be up to 155 byte, it can represent up to 254 byte
filename (but exact limit depends on the location of '/' character in
a pathname.)

Our TarWriter first attempt to use UStar extension and then fallback to
PAX extension.

But there's a bug in UStar header creation. "Suffix" part must be a NUL-
terminated string, but we didn't handle it correctly. As a result, if
your filename just 100 characters long, the last character was droppped.

This patch fixes the issue.

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

llvm-svn: 314349

Summary:
*In-source builds* of LLVM, in which a user invokes `cmake` from within the
LLVM source directory, or invokes `cmake -B/path/to/source/dir/of/llvm`,
are explicitly checked for and disallowed by LLVM's `CMakeLists.txt`.

*In-tree builds*, on the other hand, refer to when the source directories
of projects such as Clang are nested within the `llvm/tools` source
directory. These are not disallowed, and are in fact a common way of
building LLVM and Clang.

Revise the comment to match the logic underneath it: it checks for an
"in-source build", not an "in-tree build".

Reviewers: beanz

Reviewed By: beanz

Subscribers: mgorny

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

llvm-svn: 314348

This broke the windows buildbots, revert for now.

This reverts commit 24050b5ddef42f6f3306aa94d4a1f42a7893a9a7.

llvm-svn: 314347

always set LLVM_ENABLE_DUMP=ON for +Asserts builds.

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

llvm-svn: 314346

FileOutputBuffer::create() attempts to remove a target file if the file
is a regular one, which results in an unexpected result in a failure
scenario.

If something goes wrong and the user of FileOutputBuffer decides to not
call commit(), it leaves nothing. An existing file is removed, and no
new file is created.

What we should do is to atomically replace an existing file with a new
file using rename(), so that it wouldn't remove an existing file without
creating a new one.

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

llvm-svn: 314345

Summary:
Weird failure where `errno != ENOMEM` on valloc failure. The returned pointer
is null since it passes the previous assert, so this shouldn't happen.

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/10931
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/2469

Disabling until we figure out what's going on.

Reviewers: alekseyshl

Reviewed By: alekseyshl

Subscribers: aemerson, srhines, llvm-commits, kristof.beyls

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

llvm-svn: 314344

whose isa is an index instead of a pointer.  Currently, this type
of isa encoding is only used on watchos.
<rdar://problem/34675497> 

llvm-svn: 314343

Change-Id: I5594bd6b216deca2c73cf0a7001f9aec1e803c60
llvm-svn: 314342

This commit allows the outliner to avoid saving and restoring the link register
on AArch64 when it is dead within an entire class of candidates.

This introduces changes to the way the outliner interfaces with the target.
For example, the target now interfaces with the outliner using a
MachineOutlinerInfo struct rather than by using getOutliningCallOverhead and
getOutliningFrameOverhead.

This also improves several comments on the outliner's cost model.

https://reviews.llvm.org/D36721

llvm-svn: 314341

Removes semicolons after if {} blocks, function definitions, etc.
I was able to apply the large OMPT patch cleanly on top of this one
with no conflicts.

llvm-svn: 314340

Revert r314249 "Recommit r314151 "[X86] Make all the NOREX CodeGenOnly instructions into postRA pseudos like the NOREX version of TEST."""

This caused PR34751

llvm-svn: 314339

This contributed to PR34751

llvm-svn: 314338

Hopefully this will make it easier to vary the combine depth threshold per-target.

llvm-svn: 314337

ExternalASTMerger has hitherto relied on being able to look up 
any Decl through its named DeclContext chain. This works for 
many cases, but causes problems for function-local structs, 
which cannot be looked up in their containing FunctionDecl. An
example case is

void f() {
  { struct S { int a; }; }
  { struct S { bool b; }; }
}

It is not possible to lookup either of the two Ses individually 
(or even to provide enough information to disambiguate) after 
parsing is over; and there is typically no need to, since they 
are invisible to the outside world.

However, ExternalASTMerger needs to be able to complete either 
S on demand. This led to an XFAIL on test/Import/local-struct, 
which this patch removes. The way the patch works is:

It defines a new data structure, ExternalASTMerger::OriginMap,
which clients are expected to maintain (default-constructing 
if the origin does not have an ExternalASTMerger servicing it)
As DeclContexts are imported, if they cannot be looked up by 
name they are placed in the OriginMap. This allows 
ExternalASTMerger to complete them later if necessary.
As DeclContexts are imported from an origin that already has 
its own OriginMap, the origins are forwarded – but only for 
those DeclContexts that are actually used. This keeps the 
amount of stored data minimal.

The patch also applies several improvements from review:

- Thoroughly documents the interface to ExternalASTMerger;
- Adds optional logging to help track what's going on; and
- Cleans up a bunch of braces and dangling elses.

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

llvm-svn: 314336

Summary:
According to https://gcc.gnu.org/wiki/SplitStacks, the linker expects a zero-sized .note.GNU-split-stack section if split-stack is used (and also .note.GNU-no-split-stack section if it also contains non-split-stack functions), so it can handle the cases where a split-stack function calls non-split-stack function.

This change adds the sections if needed.

Fixes PR #34670.

Reviewers: thanm, rnk, luqmana

Reviewed By: rnk

Subscribers: llvm-commits

Patch by Cherry Zhang <cherryyz@google.com>

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

llvm-svn: 314335

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

llvm-svn: 314334

Revert r314284, r314285 and r314289 because of a reported
breakage in armv7k watchos builder.

llvm-svn: 314333

We already have zeroable bits in an APInt. We might as well use that instead of checking for an all zero BUILD_VECTOR.

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

llvm-svn: 314332

[X86] In combineLoopSADPattern, pad result with zeros and use full size add instead of using a smaller add and inserting.

In some cases the result psadbw is smaller than the type of the add that started the match. Currently in these cases we are using a smaller add and inserting the result.

If we instead combine the psadbw with zeros and use the full size add we can take advantage of implicit zeroing we get if we emit a narrower move before the add.

In a future patch, I want to make isel aware that the psadbw itself already zeroed the upper bits and remove the move entirely.

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

llvm-svn: 314331