GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1
we can migrate to std::is_trivially_copyable.

The Optional.h change made MSVC choke
(https://buildkite.com/llvm-project/premerge-checks/builds/18587#cd1bb616-ffdc-4581-9795-b42c284196de)
so I leave it out for now.

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

This is a child diff of D92261.

After supporting field/index-level shadow, the existing shadow with type
i16 works for only primitive types.

Reviewed-by: morehouse

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

Removes MaxParallelLevel references from rtl.cpp and drops
resulting dead code.

Reviewed By: JonChesterfield

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

[RISCV] Add additional half precision fnmadd/fnmsub tests with an fneg on the second operand instead of the first.

This matches the float/double tests added in defe1186

PowerPC ISA support the input test for vector type v4f32 and v2f64.
Replace the software compare with hw test will improve the perf.

Reviewed By: ChenZheng

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

This case for long-double semantics mismatch on OpenMP references
%clang, which should be located in Driver directory.

If its not in the PassRegistry it's not recognized as
a pass when we print before/after. Happened to notice while
I was working on a new pass.

Fix bogus diagnostics that would get confused and think a "no viable
fuctions" case was an "undeclared identifiers" case, resulting in an
incorrect diagnostic preceding the correct one. Use overload resolution
to determine which function we should select when we can find call
candidates from a dependent base class. Make the diagnostics for a call
that could call a function from a dependent base class more specific,
and use a different diagnostic message for the case where the call
target is instead declared later in the same class. Plus some minor
diagnostic wording improvements.

The function definition was removed on Feb 22, 2017 in commit
17e8d0ea.  The declaration has
remained since.

This reverts commit 3b18a594, since
apparently this doesn't work everywhere. E.g.,
clang-x86_64-debian-fast/3889
(http://lab.llvm.org:8011/#/builders/109/builds/3889) gives me:
```
+ : 'RUN: at line 8'
+ /b/1/clang-x86_64-debian-fast/llvm.obj/bin/clang -x c /dev/fd/0 -E
+ cat /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Misc/dev-fd-fs.c
fatal error: file '/dev/fd/0' modified since it was first processed
1 error generated.
```

llvm-link should not rely on the '.a' file extension when deciding if input file
should be loaded as archive. Archives may have other extensions (f.e. .lib) or no
extensions at all. This patch changes llvm-link to use llvm::file_magic to check
if input file is an archive.

Reviewed By: RaviNarayanaswamy

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

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

Support "Zfh" extension according to
https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex

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

Remove compilicated logic from CompilerInstance::InitializeSourceManager
to deal with named pipes, updating FileManager::getBufferForFile to
handle it in a more straightforward way. The existing test at
clang/test/Misc/dev-fd-fs.c covers the new behaviour (just like it did
the old behaviour).

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

Extract remote debugging logic from PlatformMacOSX and move it into
PlatformRemoteMacOSX so it can benefit from all the logic necessary for
remote debugging.

Until now, remote macOS debugging was treated almost identical to local
macOS debugging. By moving in into its own class, we can have it inherit
from PlatformRemoteDarwinDevice and all the functionality it provides,
such as looking at the correct DeviceSupport directory.

rdar://68167374

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

This reverts commit 55f8c2fd.

While I was adding a new intrinsic instruction (not overloaded), I accidentally used CreateUnaryIntrinsic to create the intrinsics, which turns out to be passing the type list to getName, and ended up naming the intrinsics function with type suffix, which leads to wierd bugs latter on. It took me a long time to debug.
It seems a good idea to add an assertion in getName so that it fails if types are passed but it's not a overloaded function.
Also, the overloade version of getName is less efficient because it creates an std::string. We should avoid calling it if we know that there are no types provided.

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

llvm-link should not rely on the '.a' file extension when deciding if input file
should be loaded as archive. Archives may have other extensions (f.e. .lib) or no
extensions at all. This patch changes llvm-link to use llvm::file_magic to check
if input file is an archive.

Reviewed By: RaviNarayanaswamy

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

As part of reducing use of PreprocessorOptions::RemappedFileBuffers,
stop abusing it to pass information around remapped files in
`ARCMigrate`.  This simplifies an eventual follow-up to switch to using
an `InMemoryFileSystem` for this.

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

In ScopedString::append va_list ArgsCopy is created but never cleanuped
which can lead to undefined behaviour, like stack corruption.

Reviewed By: cryptoad

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

due to cd95338e

Need to check if result is LValue before getLValueBase.

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

This reverts commit 542d3b60.
Seems to break check-lld. Reverting while I take a look.

Instead of computing the alignment and size of the `char` buffer in
`AlignedCharArrayUnion`, rely on the math in `std::aligned_union_t`.
Because some users of this rely on the `buffer` field existing with a
type convertible to `char *`, we can't change the field type, but we can
still avoid duplicating the logic.

A potential follow up would be to delete `AlignedCharArrayUnion` after
updating its users to use `std::aligned_union_t` directly; or if we like
our template parameters better, could update users to stop peeking
inside and then replace the definition with:
```
template <class T, class... Ts>
using AlignedCharArrayUnion = std::aligned_union_t<1, T, Ts...>;
```

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

Typing the API appropriately.

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

Both seem to fail to read values from the non-running target.

This is useful for debugging why lld loads .o files it shouldn't load.
It's also useful for users of lld -- I've used ld64's version of this a
few times.

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

When the same generic name is use-associated from two modules, the
generics are merged into a single one in the current scope. This change
fixes some bugs in that process.

When a generic is merged, it can have two specific procedures with the
same name as the generic (c.f. module m7c in modfile07.f90). We were
disallowing that by checking for duplicate names in the generic rather
than duplicate symbols. Changing `namesSeen` to `symbolsSeen` in
`ResolveSpecificsInGeneric` fixes that.

We weren't including each USE of those generics in the .mod file so in
some cases they were incorrect. Extend GenericDetails to specify all
use-associated symbols that are merged into the generic. This is used to
write out .mod files correctly.

The distinguishability check for specific procedures of a generic
sometimes have to refer to procedures from a use-associated generic in
error messages. In that case we don't have the source location of the
procedure so adapt the message to say where is was use-associated from.
This requires passing the scope through the checks to make that
determination.

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

`AlignedArrayCharUnion` is now using `alignas`, which is properly
supported now by all the host toolchains we support. As a result, the
extra `alignas` on `IntervalMap` isn't needed anymore.

This is effectively a revert of 379daa29.

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

Revert "Delete llvm::is_trivially_copyable and CMake variable HAVE_STD_IS_TRIVIALLY_COPYABLE"

This reverts commit 4d4bd40b.

This reverts commit 557b00e0.

This should fix a build failure on some systems, e.g. solaris11-sparcv9
http://lab.llvm.org:8014/#/builders/22

LLVM has TLS_(base_)addr32 for 32-bit TLS addresses in 32-bit mode, and
TLS_(base_)addr64 for 64-bit TLS addresses in 64-bit mode. x32 mode wants 32-bit
TLS addresses in 64-bit mode, which were not yet handled. This adds
TLS_(base_)addrX32 as copies of TLS_(base_)addr64, except that they use
tls32(base)addr rather than tls64(base)addr, and then restricts
TLS_(base_)addr64 to 64-bit LP64 mode, TLS_(base_)addrX32 to 64-bit ILP32 mode.

Reviewed By: RKSimon

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

Since x32 supports PC-relative address, it shouldn't use EBX for TLS
address.  Instead of checking N.getValueType(), we should check
Subtarget->is32Bit().  This fixes PR 22676.

Reviewed By: RKSimon

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

Push `FileEntryRef` and `DirectoryEntryRef` further, using it them
`Module::Umbrella`, `Module::Header::Entry`, and
`Module::DirectoryName::Entry`.

- Add `DirectoryEntryRef::operator const DirectoryEntry *` and
  `OptionalDirectoryEntryRefDegradesToDirectoryEntryPtr`, to get the
  same "degrades to `DirectoryEntry*` behaviour `FileEntryRef` enjoys
  (this avoids a bunch of churn in various clang tools).
- Fix the `DirectoryEntryRef` constructor from `MapEntry` to take it by
  `const&`.

Note that we cannot get rid of the `...AsWritten` names leveraging the
new classes, since these need to be as written in the `ModuleMap` file
and the module directory path is preprended for the lookup in the
`FileManager`.

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