Clang now incorrectly allowed increment of bool in unevaluated contexts, we set `diagnostic::ext_increment_bool` to be SFINAEFailure to fix this issue.

```
template<class T> auto f(T t) -> decltype(++t);
auto f(...) -> void;
void g() {
  f(true);  // Clang wrongly makes this a hard error
}
```

```
template <class T>
concept can_increment = requires(T t) { ++t; };

template <class T> void f() {
  static_assert(requires(T t) { ++t; }); // Incorrectly allowed
}

int main() {
  f<bool>();

  static_assert(!can_increment<bool>); // Incorrectly fails

  bool b = false;
  ++b; // Correctly rejected
}
```
Fix issue: https://github.com/llvm/llvm-project/issues/47517

Reviewed By: erichkeane

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

Reviewed By: #libc, ldionne

Spies: ldionne, libcxx-commits

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Target triple to support "x86_64-unknown-uefi"

Reviewed By: phosek

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

(missing piece from https://reviews.llvm.org/D152265)
476e7c49

Build bots are still failing, and getting it to work on Windows should
be done in a separate patch, should this even be technically feasible.

 | lld-link: error:
 | stage2_win_x64/obj/compiler-rt/lib/asan/asan_shared_library.asan_activation.obj:
 | memcpy should not refer to special section 0

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

There are two age fields in a PDB file. One from the PDB Stream and another one
from the DBI stream.

According to https://randomascii.wordpress.com/2011/11/11/source-indexing-is-underused-awesomeness/#comment-34328,
The age in DBI stream is used to against the binary's age. `Pdbstr.exe` is used
to only increment the age from PDB stream without changing the DBI age. I
also verified this by manually changing the DBI age of a PDB file and let
`windbg.exe` to load it. It shows the following logs before and after changing:

Before:
```
SYMSRV:  BYINDEX: 0xA
         c:\symbols*https://msdl.microsoft.com/download/symbols
         nlaapi.pdb
         D72AA69CD5ABE5D28C74FADB17DE3F8C1
SYMSRV:  PATH: c:\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb
SYMSRV:  RESULT: 0x00000000
*** WARNING: Unable to verify checksum for NLAapi.dll
DBGHELP: NLAapi - public symbols
        c:\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb
...
```

After:
```
SYMSRV:  BYINDEX: 0xA
         c:\symbols*https://msdl.microsoft.com/download/symbols
         nlaapi.pdb
         D72AA69CD5ABE5D28C74FADB17DE3F8C1
SYMSRV:  PATH: c:\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb
SYMSRV:  RESULT: 0x00000000
DBGHELP: c:\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb - mismatched pdb
SYMSRV:  BYINDEX: 0xB
         c:\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
         nlaapi.pdb
         D72AA69CD5ABE5D28C74FADB17DE3F8C1
SYMSRV:  PATH: c:\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb
SYMSRV:  RESULT: 0x00000000
DBGHELP: c:\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb - mismatched pdb
SYMSRV:  BYINDEX: 0xC
         c:\src\symbols*https://msdl.microsoft.com/download/symbols
         nlaapi.pdb
         D72AA69CD5ABE5D28C74FADB17DE3F8C1
SYMSRV:  PATH: c:\src\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb
SYMSRV:  RESULT: 0x00000000
*** WARNING: Unable to verify checksum for NLAapi.dll
DBGHELP: NLAapi - public symbols
        c:\src\symbols\nlaapi.pdb\D72AA69CD5ABE5D28C74FADB17DE3F8C1\nlaapi.pdb
```

So, `windbg.exe` uses the DBI age to detect mismatched pdb, but it still loads
the pdb even if the age mismatched. Probably lldb should do the same and give
some warnings.

This fixes a bug that lldb can't load some windows system pdbs due to mismatched
uuid.

Reviewed By: rnk

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

The lifetime of clang_resource_path should be same as
kResourceDirSuffixes, because kResourceDirSuffixes doesn't own
clang_resource_path.

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

In the vector distribute patterns, we used to move
`vector.broadcast`s out of `vector.warp_execute_on_lane0`s
irrespectively of how they were defined.

This could create broadcast operations with invalid semantic.
E.g.,
```
%r = warop ...[32] ... -> vector<1x2xf32> {
  %val = broadcast %in : vector<64xf32> to vetor<1x64xf32>
  vector.yield %val : vector<1x64xf32>
}
```
=>
```
%r = warop ...[32] ... -> vector<64xf32> {
  vector.yield %in : vector<64xf32>
}
// Broadcasting to a narrower type!
broadcast %r : vector<64xf32> to vector<1x2xf32>
```

The root issue is we are trying to broadcast something that is not the same
for each thread, so there is actually nothing to propagate here.

The fix checks that the broadcast we want to create actually makes sense.

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

The `TrackConstraintBRVisitor` should accept a message for the note
instead of creating one. It would let us inject domain-specific
knowledge in a non-intrusive way, leading to a more generic visitor.

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

Causes miscompile. See https://reviews.llvm.org/D141188.

This reverts commit fb2c98a9

This patch adds support for the OpenMP 4.0 depend clause for the task
construct, excluding array sections, to Flang lowering from parse-tree
to MLIR.

Reviewed By: kiranchandramohan

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

D135716 introduced -ftrivial-auto-var-init=pattern where supported.
Unfortunately this introduces unwanted memset() for large stack arrays,
as shown by the new tests added for asan and msan (tsan already had this
test).

In general, the problem of compiler-inserted memintrinsic calls
(memset/memcpy/memmove) is not new to compiler-rt, and has been a
problem before.

To avoid introducing unwanted memintrinsic calls, we redefine
memintrinsics as __sanitizer_internal_mem* at the assembly level for
most source files automatically (where sanitizer_common_internal_defs.h
is included).

In few cases, redefining a symbol in this way causes issues for
interceptors, namely the memintrinsic interceptor themselves. For such
source files we have to selectively disable the redefinition.

Other alternatives have been considered, but simply do not work well in
the context of compiler-rt:

	1. Linker --wrap:  this does not work because --wrap only
	   applies ...

The current interface requires some rather ugly tracking of state due to
splitting up the calls for each argument. Instead, pack them all into a
single call by passing an ArrayRef. Also clean up the dodgy whitespace
emitted for the directive whilst here; there was a stray space between
the tab and .option, and there was a tab rather than a space after the
first comma for some strange reason.

Reviewed By: craig.topper

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

Currently the early-return flow in the infinite loop makes it hard to
find the non-error termination points amongst the sea of errors. Rewrite
it with a more conventional control flow that has a clear loop guard (in
place of one of the early returns) and a break (in place of the other),
and with greater code reuse.

This has a small effect on the errors given for malformed input, as seen
in the affected test, and is probably more helpful as a result. Note
that we also bail early now if parseComma fails, as is standard.

Reviewed By: craig.topper

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

Make use of a physical copy, rather than real FS in unittests that
change working-directory to get rid of the side effect of changing cwd for the
whole process. It's triggering crashes depending on the test order.

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

[GlobalISel][X86] Move G_SEXT_INREG legalization handling to beside the regular integer extension legalizations

This change to llvm-objcopy preserves the ELF section sh_link to .symtab
so long as none of the symbol table indices have been changed.
Previously, any invocation of llvm-objcopy including a "no-op" would
clear any section sh_link to .symtab.

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

Removing them seems to slightly increase code quality as well as
simplifying both the tablegen and C++ parts of the code.

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

Fixes #63119

Reviewed By: #clang-language-wg, aaron.ballman

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

Most indexed vector instructions are suffixed with v<N><TY>_indexed.

SQRDMLAH/SQRDMLSH are the exception, being suffixed with <TY>_indexed
instead, which can complicate matching them slightly.

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

Set public specifiers only for constructor and inherited methods from
MCObjectWriter and leave others as private. Also change the order of
MCObjectWriter methods' definition according to it's declaration order.

Reviewed By: skan

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

Replace the legacy legalizer versions

In https://reviews.llvm.org/D127762#4102578 @erichkeane suggested to
limit size of this field to 16bits, such that the field that encodes the
SME attributes for a function fall within the alignment of the struct for
32bit platforms.

Standard implimits defines the minimum handlers per try block to 256,
which suggests that 16bits should be more than sufficient for most
programs. Erich also pointed out that exception specs are being
deprecated and are rarely used, so hopefully this change is safe to make.

Reviewed By: erichkeane

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

This reverts commit 6d5a653d.

New metadata format contains full calculation of field contents for
ps_extra_lds_size (vs old format where the value in RSRC register is used by PAL
to calculate the value required).

Also stop updating float_mode and rely on front end settings for this field.

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

Mixing -mfloat-abi=hard with a CPU that doesn't have floating point
registers is an error in GCC:
  cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU

Since there is code in the wild (including in clang tests) that relies
on Clang's current behaviour, emit a warning instead of an error.

Unlike the GCC error, the new warning refers to floating point
registers instead of an FPU. This is because -mfloat-abi=hard and
-march=armv8.1-m.main+mve+nofp are compatible - in that case floating
point registers are required, but an FPU is not required.

My initial thought was to use the floating point ABI calculated by
arm::getARMFloatABI() but in invalid cases which error for other
reasons the ABI is miscalculated and the warning would cause confusion.
Therefore only warn if the user specifies the float ABI explicitly.

Fixes part of https://github.com/llvm/llvm-project/issues/55755

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

Reviewed By: RKSimon

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

An associated -W flag is needed.

This reverts commit 1d511e18.

* Remove `transform::PatternRegistry`.
* Add a new op for each currently registered pattern set.
* Change names of vector dialect pattern selector ops, so that they are consistent with the remaining code base.
* Remove redundant `transform.vector.extract_address_computations` op.

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