*San flagged issues should be now be addressed.

llvm-svn: 366399

Found by UBSan.

llvm-svn: 366398

Issue found by ASan.

llvm-svn: 366397

[AArch64] Add dependency from AArch64CodeGen to TransformUtils to fix -DBUILD_SHARED_LIBS=on link error after D64173/r366361

This fixes:

ld.lld: error: undefined symbol: llvm::findAllocaForValue(llvm::Value*, llvm::DenseMap<llvm::Value*, llvm::Alloc aInst*, llvm::DenseMapInfo<llvm::Value*>, llvm::detail::DenseMapPair<llvm::Value*, llvm::AllocaInst*> >&)
>>> referenced by AArch64StackTagging.cpp

llvm-svn: 366396

Summary:
When doing standalone builds, you could potentially be building against
an llvm which also built lldb. If this were the case, you'd be
attempting to build this target twice.

Reviewers: xiaobai

Subscribers: mgorny

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

llvm-svn: 366394

(At the moment, we ignore the alignment requirement.)

llvm-svn: 366393

TableGen is a host tool and requires a native variant for every build.
While building as a part of llvm this is trivial and llvm handles it.
However, building standalone means that lldb has to handle this itself.
Add a NATIVE build variant to enable this.

llvm-svn: 366392

Summary:
Integer Set Library using retain-count based allocation which is not
modeled in MallocChecker.

Reviewed By: NoQ

Tags: #clang

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

llvm-svn: 366391

llvm-svn: 366390

It turns out that this test was only passing by accident. It was relying on
the optimizer to remove the only reference to A's vtable by realizing that
the CFI check will always fail. The vtable contains a reference to RTTI in
libc++, which will be unresolved because the C driver won't link against it.

This was found by my prototype implementation of HWASAN for globals, which
happens to end up preserving the reference.

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

llvm-svn: 366389

Summary:
LoopInfoWrapperPass::verify uses DT, which means DT must be alive
even if it has no direct users.

Fixes a crash in expensive checks mode.

Reviewers: pcc, leonardchan

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 366388

After rL365286 I had failing test:
  LLVM :: tools/gold/X86/v1.12/thinlto_emit_linked_objects.ll

It was failing with the output:
$ llvm-bcanalyzer --dump llvm/test/tools/gold/X86/v1.12/Output/thinlto_emit_linked_objects.ll.tmp3.o.thinlto.bc
Expected<T> must be checked before access or destruction.
Unchecked Expected<T> contained error:
Unexpected end of file reading 0 of 0 bytesStack dump:

Change-Id: I07e03262074ea5e0aae7a8d787d5487c87f914a2
llvm-svn: 366387

- getCompression() used to return a PDB_SourceCompression even though
  the docs for IDiaInjectedSource are explicit about the return value
  being compiler-dependent. Return an uint32_t instead, and make the
  printing code handle unknown values better by printing "Unknown" and
  the int value instead of not printing any compression.

- Print compressed contents as hex dump, not as string.

- Add compression type "DotNet", which is used (at least) by csc.exe,
  the C# compiler. Also add a lengthy comment describing the stream
  contents (derived from looking at the raw hex contents long enough
  to see the GUIDs, which led me to the roslyn and mono implementations
  for handling this).

- The native injected source dumper was dumping the contents of the
  whole data stream -- but csc.exe writes a stream that's padded with
  zero bytes to the next 512 boundary, and the dia api doesn't display
  those padding bytes. So make NativeInjectedSource::getCode() do the
  same thing.

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

llvm-svn: 366386

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

llvm-svn: 366385

llvm-svn: 366384

llvm-svn: 366383

[X86] Make sure we mark 128/256 MLOAD as Legal with VLX when min-legal-vector-width=256 is in effect.

This started triggering an assertion after r364718 when we made
these Custom under AVX2.

llvm-svn: 366382

to make sure it was correctly being disabled after this test
case completed.

llvm-svn: 366381

llvm-svn: 366380

This will let us instrument globals during initialization. This required
making the new PM pass a module pass, which should still provide access to
analyses via the ModuleAnalysisManager.

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

llvm-svn: 366379

If a core file has an EFI version string which includes a UUID
(similar to what it returns for the kdp KDP_KERNELVERSION packet)
in the LC_IDENT or LC_NOTE 'kern ver str' load command.  In that
case, we should try to find the binary and dSYM for the UUID
listed.  The dSYM may have python code which knows how to relocate
the binary to the correct address in lldb's target section load
list and loads other ancillary binaries.

The test case is a little involved,

1. it compiles an inferior hello world apple (a.out),
2. it compiles a program which can create a corefile manually
   with a specific binary's UUID encoded in it,
3. it gets the UUID of the a.out binary,
4. it creates a shell script, dsym-for-uuid.sh, which will
   return the full path to the a.out + a.out.dSYM when called
   with teh correct UUID,
5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before
   creating the lldb target, to point to this dsym-for-uuid.sh,
6. runs the create-corefile binary we compiled in step #2,
7. loads the corefile from step #6 into lldb,
8. verifies that lldb loaded a.out by reading the LC_NOTE
   load command from the corefile, calling dsym-for-uuid.sh with
   that UUID, got back the path to a.out and loaded it.

whew!

<rdar://problem/47562911>

llvm-svn: 366378

Scope of changes:
1. Moved buildSchedule functions to ScopBuilder.
2. Moved combineInSequence function to ScopBuilder.
3. Moved mapToDimension function to ScopBuilder.
4. Moved LoopStackTy to ScopBuilder.
5. Moved getLoopSurroundingScop to ScopHelper.
6. Moved getNumBlocksInLoop to ScopHelper.
7. Moved getNumBlocksInRegionNode to ScopHelper.
8. Moved getRegionNodeLoop to ScopHelper.

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

llvm-svn: 366377

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

llvm-svn: 366376

Depending on the evaluation order of function call arguments,
the current code may insert a use before def.

llvm-svn: 366375

Scope of changes:
1) Moved finalizeAccesses to ScopBuilder
2) Moved updateAccessDimensionality to ScopBuilder
3) Moved foldSizeConstantsToRight to ScopBuilder
4) Moved foldSizeConstantsToRight to ScopBuilder
5) Moved assumeNoOutOfBounds to ScopBuilder
6) Moved markFortranArrays to ScopBuilder
7) Added iterator range for AccessFunctions vector.

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

llvm-svn: 366374

llvm-svn: 366373

llvm-svn: 366372

The LocalStackSlotPass pre-allocates a stack protector and makes sure
that it comes before the local variables on the stack.

We need to make sure that later during PEI we don't re-allocate a new
stack protector slot. If that happens, the new stack protector slot will
end up being **after** the local variables that it should be protecting.

Therefore, we would have two slots assigned for two different stack
protectors, one at the top of the stack, and one at the bottom. Since
PEI will overwrite the assigned slot for the stack protector, the load
that is used to compare the value of the stack protector will use the
slot assigned by PEI, which is wrong.

For this, we need to check if the object is pre-allocated, and re-use
that pre-allocated slot.

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

llvm-svn: 366371

In preparation of a fix, add tests for multiple backends.

llvm-svn: 366370

Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex() >=
0`.

llvm-svn: 366369

As discussed in D64780 the wording of this warning message is being
changed to say 'is not supported' instead of 'ignored', and the
diag ID itself is being changed to warn_cconv_not_supported.

llvm-svn: 366368

Extract the sources to the GCD of the original size and target size,
padding with implicit_def as necessary.

Also fix the case where the requested source type is wider than the
original result type. This was ignoring the type, and just using the
destination. Do the operation in the requested type and truncate back.

llvm-svn: 366367

Use an anyext to the requested type for the leftover operand to
produce a slightly wider type, and then truncate the final merge.

I have another implementation almost ready which handles arbitrary
widens, but I think it produces worse code in this example (which I
think is 90% due to not folding redundant copies or folding out
implicit_def users), so I wanted to add this as a baseline first.

llvm-svn: 366366

In ClangASTContext::CreateFunctionTemplateSpecializationInfo a TemplateArgumentList is allocated on the stack but is treated as if it is persistent in subsequent calls. When we exit the function func_decl will still point to the stack allocated memory. We will use TemplateArgumentList::CreateCopy instead which will allocate memory out of the DeclContext.

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

llvm-svn: 366365

While the in-place hints on valid formats are up to date (e.g. when
choosing an invalid format expr -f nonExisting -- 42), the corresponding
online docs table is not. The formats "address", "hex float",
"instruction" and "void" are missing, and "decimal" refers to an
outdated abbreviation 'i' instead of 'd'.

Patch by: Lukas Böger

Differential revision: https://reviews.llvm.org/D63813

llvm-svn: 366364

I'm pretty sure there's no need to have this logic living in
LLDBStandalone. It doesn't appear anything in LLVM depends on this, and
We always go through LLDBConfig.cmake which has the canonical way to
find the Python libs and interpreter for LLDB.

Differential revision: https://reviews.llvm.org/D64821

llvm-svn: 366363

When doing a standalone build, without setting LLDB_PATH_TO_LLVM_BUILD
or LLDB_PATH_TO_CLANG_BUILD, you get the following error.

```
CMake Error at cmake/modules/LLDBStandalone.cmake:23 (find_package):
  Could not find a package configuration file provided by "LLVM" with any of
  the following names:

    LLVMConfig.cmake
    llvm-config.cmake

  Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
  "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
  provides a separate development package or SDK, be sure it has been
  installed.
```

This suggests setting LLVM_DIR to LLVM's install directory. However,
LLDBStandalone.cmake takes LLDB_PATH_TO_LLVM_BUILD as its hint. As
someone who isn't familiar with the standalone process, this is rather
confusing. This patch removes LLDB_PATH_TO_LLVM_BUILD and
LLDB_PATH_TO_CLANG_BUILD and instead use LLVM_DIR and Clang_DIR
respectively.

Differential revision: https://reviews.llvm.org/D64823

llvm-svn: 366362

Summary:
Use MTE intrinsics to tag stack variables in functions with
sanitize_memtag attribute.

Reviewers: pcc, vitalybuka, hctim, ostannard

Subscribers: srhines, mgorny, javed.absar, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 366361

Implement IR intrinsics for stack tagging. Generated code is very
unoptimized for now.

Two special intrinsics, llvm.aarch64.irg.sp and llvm.aarch64.tagp are
used to implement a tagged stack frame pointer in a virtual register.

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

llvm-svn: 366360

rdar://53015486

llvm-svn: 366359