[SCEV] Fix potentially empty set for unsigned ranges

The following commit enabled the analysis of ranges for heap allocations:
22ca38da25e19a7c5fcfeb3f22159aba92ec381e

The range turns out to be empty in cases such as the one in test (which
is [1,1)), leading to an assertion failure. This patch fixes for the
same case.

Fixes https://github.com/llvm/llvm-project/issues/63856

Reviewed By: fhahn

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

(cherry picked from commit 0609b65aaf03b083d282a4ffe8bf660351dac461)

[CodeGen] Fix incorrect insertion point selection for reduction nodes in ComplexDeinterleavingPass

When replacing ComplexDeinterleavingPass::ReductionOperation, we can do it
either from the Real or Imaginary part. The correct way is to take whichever
is later in the BasicBlock, but before the patch, we just always took the
Real part.

Fixes https://github.com/llvm/llvm-project/issues/65044

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

(cherry picked from commit e2cb07c322e85604dc48f9caec52b3570db0e1d8)

[CodeGen][AArch64] Commit test for #65044

(cherry picked from commit 2fce8f74b3c04bbf7e941cfed7604edae2b573b6)

[libc++][hardening] Remove hardening from release notes, undeprecate safe mode

This patch effectively maintains the status quo, making sure that the
safe mode keeps working the same way as before. Hardening will target
the next major release, allowing it to go through RFC and for the
implementation to stabilize and mature.

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

[LoopVectorize] Fix incorrect order of invariant stores when there are multiple reductions.

When a loop has multiple reductions, each with an intermediate invariant
store, the order in which those reductions are processed is not considered.
This can result in the invariant stores outside the loop not preserving the
original order.
This patch sorts VPReductionPHIRecipes by the order in which they have
stores in the original loop before running
`InnerLoopVectorizer::fixReduction` function, and it helps to maintain
the correct order of stores.

Fixes https://github.com/llvm/llvm-project/issues/64047

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

(cherry picked from commit ac65fb869977185b44757b94dc5130bd08c6f7e2)

[LoopVectorize] Pre-commit tests for D157631

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

(cherry picked from commit 2df9ed11c51ebf6d19f7cb22c3794d1bd460ddf8)

[RelNotes] Add more details on the removal of the legacy optimization pipeline

[mlir][nfc] Allow ops to have operands/attributes named `context`.

This is probably a bad idea, but it's only become a problem with properties and is easy to fix.

Reviewed By: mehdi_amini

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

[JumpThreading] Invalidate LVI after `combineMetadataForCSE`.

(cherry picked from commit 7ded71b1e43fff0be3acb74038bfea87f38d5cfa)

[JumpThreading][NFC] Pre-commit for invalid LVI.

(cherry picked from commit 5855a4be9cbc3c4584d8a1632886c347044dfbef)

Revert "[clang][Docs] Added release note for D142609"

The associated commit was reverted and backported in a93ca35, so this
release note line should also be removed.

This reverts commit 061e855767dbe0821d81a8d47158f468dd00ae5f.

[clang][clangd] Ensure the stack bottom before building AST

`clang::runWithSufficientStackSpace` requires the address of the
initial stack bottom to prevent potential stack overflows.

In addition, add a fallback to ASTFrontendAction in case any client
forgets to call it when not through CompilerInstance::ExecuteAction,
which is rare.

Fixes https://github.com/clangd/clangd/issues/1745.

Reviewed By: sammccall

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

(cherry picked from commit e257c0a9190637e44e292271103a13d70bec4b03)

[clang] Construct ExprRequirement with SubstitutionDiagnostic on SubstFailure

We're expecting a SubstitutionDiagnostic in diagnoseUnsatisfiedRequirement
if the status of ExprRequirement is SubstFailure. Previously, the Requirement
was created with Expr on SubstFailure by mistake, which could lead to the
assertion failure in the subsequent diagnosis.

Fixes https://github.com/clangd/clangd/issues/1726
Fixes https://github.com/llvm/llvm-project/issues/64723
Fixes https://github.com/llvm/llvm-project/issues/64172

In addition, this patch also fixes an invalid test from D129499.

Reviewed By: erichkeane

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

[NFC][Clang] Fix static analyzer concern about null value dereference

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

[sanitizer] scanf interceptor: fix write size for %mc/%mC/%mS

When the optional assignment-allocation character 'm' (Extension to the
ISO C standard) is present, we currently use internal_strlen(buf)+1 for
all of cCsS[ (D85350). Fix cCS to use the correct size.

Fix https://github.com/llvm/llvm-project/issues/61768

Reviewed By: #sanitizers, vitalybuka

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

(cherry picked from commit beeb37a8f3275281be305d2d1afe35ca053e21c0)

[CodeGen] First check the kind and then the llvm::Function properties.

This patch fixes valgrind reports from downstream consumers about conditional
jump over uninitialised memory.

The original report:

```[ RUN      ] ScopeReflectionTest.IsComplete
==987150== Conditional jump or move depends on uninitialised value(s)
==987150==    at 0x1E1128F: clang::CodeGen::CodeGenModule::SetLLVMFunctionAttributesForDefinition(clang::Decl const*, llvm::Function*) (CodeGenModule.cpp:2391)
==987150==    by 0x1E4F181: clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:5669)
==987150==    by 0x1E4A194: clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:3909)
==987150==    by 0x1E4A752: clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (CodeGenModule.cpp:3649)
==987150==    by 0x1E532F5: clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.0] (CodeGenModule.cpp:6563)
==987150==    by 0x1B0BEDD: (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) (ModuleBuilder.cpp:190)
==987150==    by 0x1AEA47B: clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (CodeGenAction.cpp:235)
==987150==    by 0x101B02F: clang::IncrementalASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (IncrementalParser.cpp:52)
==987150==    by 0x101ED93: clang::IncrementalParser::ParseOrWrapTopLevelDecl() (IncrementalParser.cpp:276)
==987150==    by 0x101FBBC: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:342)
==987150==    by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150==    by 0xE734C0: Cpp::Interpreter::Parse(llvm::StringRef) (CppInterOpInterpreter.h:172)
==987150==  Uninitialised value was created by a heap allocation
==987150==    at 0x844BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==987150==    by 0x1B0C882: StartModule (ModuleBuilder.cpp:139)
==987150==    by 0x1B0C882: clang::CodeGenerator::StartModule(llvm::StringRef, llvm::LLVMContext&) (ModuleBuilder.cpp:360)
==987150==    by 0x101C4AF: clang::IncrementalParser::GenModule() (IncrementalParser.cpp:372)
==987150==    by 0x101FC0E: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:362)
==987150==    by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150==    by 0x100E243: clang::Interpreter::create(std::unique_ptr<clang::CompilerInstance, std::default_delete<clang::CompilerInstance> >) (Interpreter.cpp:279)
==987150==    by 0xF2131A: compat::createClangInterpreter(std::vector<char const*, std::allocator<char const*> >&) (Compatibility.h:123)
==987150==    by 0xF22AB9: Cpp::Interpreter::Interpreter(int, char const* const*, char const*, std::vector<std::shared_ptr<clang::ModuleFileExtension>, std::allocator<std::shared_ptr<clang::ModuleFileExtension> > > const&, void*, bool) (CppInterOpInterpreter.h:146)
==987150==    by 0xF1827A: CreateInterpreter (CppInterOp.cpp:2494)
==987150==    by 0xECFA0E: TestUtils::GetAllTopLevelDecls(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<clang::Decl*, std::allocator<clang::Decl*> >&, bool) (Utils.cpp:23)
==987150==    by 0xE9CB85: ScopeReflectionTest_IsComplete_Test::TestBody() (ScopeReflectionTest.cpp:71)
==987150==    by 0xF0ED0C: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /home/vvassilev/workspace/builds/scratch/cppyy/InterOp/build-with-clang-repl-release/unittests/CppInterOp/CppInterOpTests)
==987150==
```

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

(cherry picked from commit 92246a9be0ba47788ada9621bef58ce7819be526)

[Driver] Report warnings for unclaimed TargetSpecific options for assembler input

This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```

It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```

I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.

Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.

Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.

Modify my AIX cleanup cd18efb61d759405956dbd30e4b5f2720d8e1783 to
add an err_drv_unsupported_opt_for_target.

Reviewed By: thesamesam

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

(cherry picked from commit e9d454d1c195958645fb0948f8b97262e7f8b33a)

[AArch64] Fix arm neon vstx lane memVT size

StN lane memory size set too big lead to alias analysis goes wrong.

Fixes https://github.com/llvm/llvm-project/issues/64696

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

(cherry picked from commit db8f6c009e5a17d304be7404e50eb20b2dd0c75b)

[llvm-windres] Implement the windres flag --use-temp-file

Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.

When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.

The xz project uses the --use-temp-file flag when invoking
GNU windres, see
https://github.com/tukaani-project/xz/commit/6b117d3b1fe91eb26d533ab16a2e552f84148d47.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.

That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.

Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)

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

(cherry picked from commit 2bcc0fdc58a220cb9921b47ec8a32c85f2511a47)

[Tooling/Inclusion] Add std::range symbols in the mapping.

Fixes https://github.com/llvm/llvm-project/issues/64191

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

(cherry picked from commit 171868dc2cd60c6e3eaeb3861b18ba0e22461291)

[sanitizer][test] -std=c2x instead of -std=c23

Adjust tests from dd230efe703f34678ce52280e50238abf908aaa1 to use
-std=c2x instead, as Clang in release/17.x doesn't support -std=c23.

[Driver] Adjust -fsanitize=function & -mexecute-only interop after D158614

clangDriver depends on clangBasic, so clangBasic should not depend on
clangDriver, even just its header. Also remove clangBasic's dependency
on LLVMOption.

The issue can be seen through the bazel commit
d26dd681f9726ed7d43d7c0bdd8ee3cb2db69a2b which is reverted now.

Add hasFlagNoClaim and use it as we don't want to suppress
-Wunused-command-line-argument for -mexecute-only just because
-fsanitize= is specified.

[UBSan] Disable the function and kcfi sanitizers on an execute-only target.

An execute-only target disallows data access to code sections.
-fsanitize=function and -fsanitize=kcfi instrument indirect function
calls to load a type hash before the function label. This results in a
non-execute access to the code section and a runtime error.

To solve the issue, -fsanitize=function should not be included in any
check group (e.g. undefined) on an execute-only target. If a user passes
-fsanitize=undefined, there is no error and no warning. However, if the
user explicitly passes -fsanitize=function or -fsanitize=kcfi on an
execute-only target, an error will be emitted.

Fixes: https://github.com/llvm/llvm-project/issues/64931.

Reviewed By: MaskRay, probinson, simon_tatham

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

[X86][BF16] Lower FP_ROUND for vector types under AVX512BF16

Reviewed By: RKSimon

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

(cherry picked from commit b667e9c23d6d2f1c7371eb4a03b30de4a6f8b7b6)

[X86][BF16] Add test coverage for AVX-NE-CONVERT

Split from D158952.

(cherry picked from commit 30ec9473c6685d64d5caa17e2a6e8f4ccf275159)

[clangd] Respect IWYU keep pragma for standard headers.

see the issue https://github.com/llvm/llvm-project/issues/64191

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

(cherry picked from commit dcb28244faa88cb566a852533790bcac75daaa0f)

[RISCV] Prevent tryToFoldBNEOnCmpXchgResult from deleting AND if it has others users.

This disables the transform if the branch does not have the kill
flag set for the AND we want to delete.

Ideally we'd be able to share the AND with the AND we create in
the expansion, but that's a more complex transform. So this starts
with the simple approach to fix miscompile.

This should be backported to LLVM 17.

Fixes PR65025.ll

Reviewed By: asb

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

(cherry picked from commit ff6d33382faf3709fa270ae0abb8d165142df9ae)

[PowerPC][lld] Account for additional X-Forms -> D-Form/DS-Forms load/stores when relaxing initial-exec to local-exec

D153645 added additional X-Form load/stores that can be generated for TLS accesses.
However, these added instructions have not been accounted for in lld. As a result,
lld does not know how to handle them and cannot relax initial-exec to local-exec
when the initial-exec sequence contains these additional load/stores.

This patch aims to resolve https://github.com/llvm/llvm-project/issues/64424.

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

(cherry picked from commit 698b45aa902de4d30c798e8d6bd080c8e31bade8)

[AArch64] Add Defs=[NZCV] to MTE loop pseudos.

The `STGloop` family of pseudo-instructions all expand to a loop which
iterates over a region of memory setting all its MTE tags to a given
value. The loop writes to the flags in order to check termination. But
the unexpanded pseudo-instructions were not marked as modifying the
flags. Therefore it was possible for one to end up in a location where
the flags were live, and then the loop would corrupt them.

We spotted the effect of this in a libc++ test involving a lot of
complicated inlining, and haven't been able to construct a smaller
test case that demonstrates actual incorrect output code. So my test
here is just checking that `implicit-def $nzcv` shows up on the
pseudo-instructions as they're output from isel.

Reviewed By: DavidSpickett

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

(cherry picked from commit b09c575975b691e988a0f2e31d632c5f1038ab1d)

[libc++][format] Fixes out of bounds access.

Fixes https://llvm.org/PR65011

Reviewed By: #libc, ldionne

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

(cherry picked from commit 8930d04d5580c6a2cf04545c87387cd150cd7b46)

[lldb][windows] _wsopen_s does not accept bits other than `_S_IREAD | _S_IWRITE`

When sending file from a Linux host to a Windows remote, Linux host will try to copy the source file's permission bits, which will contain `_S_I?GRP` and `_S_I?OTH` bits. Those bits are rejected by `_wsopen_s`, causing it to return EINVAL.

This patch masks out the rejected bits.

GitHub issue: #64313

Reviewed By: jasonmolenda, DavidSpickett

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

(cherry picked from commit 9a4b3fdb82327e808213070fd157be3c557b8b9d)

[RISCV] Fix assertion failure when zcmp extension is enabled.

Before accessing "getOpcode" thorugh machine instruction, check if the iterator
has reached the end of Machine basic block otherwise we will crash at the
assertion `!NodePtr->isKnownSentinel()`.

The above assertion is hit in "Prologue/Epilogue Insertion & Frame Finalization
pass".

Reviewed By: craig.topper, wangpc

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

(cherry picked from commit fdef7952cbc26fd31d0d92a4f14dde58bc461fe9)

[mlir] Fix infinite recursion in alias initializer

The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable.

This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle.

This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children.
This incidentally makes the non-deferrable marking also `O(n)` instead of `O(n^2)` (although not performance sensitive obviously).

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

[mlir] Fix crash when adding nested dialect extensions

A dialect extension can add additional dialect extensions in its `apply` function. This used to crash when the vector of `extensions` was internally reallocated while it is being iterated over.

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

[mlir][math] Modify math.powf to handle negative bases.

Powf expansion currently returns NaN when the base is negative.
This is because taking natural log of a negative number gives
NaN. This patch will square the base and half the exponent, thereby
getting around the negative base problem.

Reviewed By: rsuderman

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

[mlir][memref] Fix crash in SubViewReturnTypeCanonicalizer

`SubViewReturnTypeCanonicalizer` is used by `OpWithOffsetSizesAndStridesConstantArgumentFolder`, which folds constant SSA value (dynamic) sizes into static sizes. The previous implementation crashed when a dynamic size was folded into a static `1` dimension, which was then mistaken as a rank reduction.

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

[PowerPC] Update V17.0.0 release notes

[clang][test] Make check pattern shorter

A check pattern in clang/test/SemaCXX/template-64605.cpp contains template
specialization kind (the text "implicit_instantiation"). It does not need to
be checked and can be safely removed.

Presence of this text in the check pattern prevents from backporting some
commits to the release branch: https://github.com/llvm/llvm-project/issues/64605.
It has only recently been printed and the relevant commit is not present in
the release/17.x branch.

(cherry picked from commit 8859c644ede4898f90f77dcad2286de08a9ba62e)

[clang] Run test for concrete target

The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.

(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)

[clang] Set FP options in Sema when instantiating CompoundStmt

When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.

To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.

This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).

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

(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)

workflows: Fix libclang-abi test after update to use download-artifac… (#64877)

workflows: Fix libclang-abi test after update to use download-artifact v3

Silently accept -Wgnu-empty-initializer

https://github.com/llvm/llvm-project/commit/5d8aaad4452f60ba8902e921d9bed606713a8f26
removed the warning group as the functionality is no longer a GNU
extension. However, users have asked for the warning group to be
supported so that code transitioning from Clang 16 to Clang 17 has an
easier migration path when compiling with -Werror. This patch restores
the warning group, but as an ignored warning group because the
functionality is now always considered to be a C extension rather than
a GNU extension. This allows users to do:

  -Werror -pedantic -Wno-gnu-empty-intializer -Wno-c2x-extensions

to silence the diagnostics in both Clang 16 and Clang 17.

Fixes https://github.com/llvm/llvm-project/issues/64357
Differential Revision: https://reviews.llvm.org/D157503

(cherry picked from commit 151214b40d869455666ca76548a9e3ad639f79de)

[CMake] Add a few more missing dependencies on ClangDriverOptions

This often breaks modules-enabled bootstrap builds.

(cherry picked from commit 1e4d6122cda6529781ecf467c2ae84e5dd41acdf)

[clang-format] Exclude kw_decltype in RemoveParentheses

From https://en.cppreference.com/w/cpp/language/decltype:
Note that if the name of an object is parenthesized, it is treated as an
ordinary lvalue expression, thus decltype(x) and decltype((x)) are often
different types.

Fixes #64786.

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

(cherry picked from commit e3a79503a30f8c9d8fba79f3e5427bb895f320cf)

[RISCV] Don't relax policy to ta when vmerge's VL shrinks during folding

When folding a vmerge into its operands, if the resulting VL is smaller than
what the vmerge had originally then what was previously in its body then gets
moved to the tail. In that case, we can't relax the tail policy to agnostic
when the merge operand is undefined, since we need to preserve these elements
past the new VL.

Fixes https://github.com/llvm/llvm-project/issues/64754

Reviewed By: craig.topper, reames

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

(cherry picked from commit 007b41b3939832b6938bb1ba91e9febebf93d3b8)

[RISCV] Add test case showing vmerge fold miscompile with tail policy

Reviewed By: reames

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

(cherry picked from commit 6e532f94eb0e2c9c93a3d75b4cf53bf12ab9f518)

Function multi-versioning: disable ifunc for ELF targets other than glibc/Android/FreeBSD

Generalize D127933 (Fuchsia special case) to other ELF targets. Ensure
that musl, NetBSD, OpenBSD, etc do not get ifunc codegen which is
unsupported in their rtld.

Link: https://discourse.llvm.org/t/does-ifunc-use-from-llvm-require-os-support/67628
Close: https://github.com/llvm/llvm-project/issues/64631
(cherry picked from commit 0c3a02b8c09bb408a74a638a263e51d67c92ca74)

[msan] Fix compilation on non-glibc

SANITIZER_GLIBC is always defined so should be tested with an if not an
ifdef.

Fixes: ad7e2501000d

Reviewed By: MaskRay

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

(cherry picked from commit 692344d87357ded619d216b265a9375f4326d8fb)

[compiler-rt] [test] Adjust an XFAIL for strtoll_strict.c for MinGW targets

8033231240f223dc7c718d1d27ece2dbcc8057c6 made this test pass
in MinGW environments, even if it still is failing in MSVC
environments.

(cherry picked from commit 277fc9475fb89c0b80d4237dbc8d698a55203c0d)

[sanitizer] Intercept glibc 2.38 __isoc23_* functions

`strtol("0b1", 0, 0)` can be (pre-C23) 0 or (C23) 1.
`sscanf("0b10", "%i", &x)` is similar. glibc 2.38 introduced
`__isoc23_strtol` and `__isoc23_scanf` family functions for binary
compatibility.

When `_ISOC2X_SOURCE` is defined (implied by `_GNU_SOURCE`) or
`__STDC_VERSION__ > 201710L`, `__GLIBC_USE_ISOC2X` is defined to 1 and
these `__isoc23_*` symbols are used.

Add `__isoc23_` versions for the following interceptors:

* sanitizer_common_interceptors.inc implements strtoimax/strtoumax.
  Remove incorrect FIXME about https://github.com/google/sanitizers/issues/321
* asan_interceptors.cpp implements just strtol and strtoll. The default
  `replace_str` mode checks `nptr` is readable and `endptr` is writable.
  atoi reuses the existing strtol interceptor.
* msan_interceptors.cpp implements strtol family functions and their
  `_l` versions. Tested by lib/msan/tests/msan_test.cpp
* sanitizer_common_interceptors.inc implements scanf family functions.

The strtol family functions are spreaded, which is not great, but the
patch (intended for release/17.x) does not attempt to address the issue.

Add symbols to lib/sanitizer_common/symbolizer/scripts/global_symbols.txt to
support both glibc pre-2.38 and 2.38.

When build bots migrate to glibc 2.38+, we will lose test coverage for
non-isoc23 versions since the existing C++ unittests imply `_GNU_SOURCE`.
Add test/sanitizer_common/TestCases/{strtol.c,scanf.c}.
They catch msan false positive in the absence of the interceptors.

Fix https://github.com/llvm/llvm-project/issues/64388
Fix https://github.com/llvm/llvm-project/issues/64946

Link: https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00010.html
("The GNU C Library version 2.38 is now available")

Reviewed By: #sanitizers, vitalybuka, mgorny

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

(cherry picked from commit ad7e2501000da2494860f06a306dfe8c08cc07c3)

[asan] Intercept atoll and strtoll on Windows

`_MSC_VER>=1800` (Visual Studio 2013) supports atoll/strtoll.
Remove the obsoleted workaround ASAN_INTERCEPT_ATOLL_AND_STRTOLL.

test/asan/TestCases/atoll_strict.c passes but
test/asan/TestCases/strtoll_strict.c doesn't.

(cherry picked from commit 8033231240f223dc7c718d1d27ece2dbcc8057c6)

[clang] Update NumFunctionDeclBits for FunctionDeclBitfields

NumFunctionDeclBits is not updated when DeductionCandidateKind is
incremented.

Fixes https://github.com/llvm/llvm-project/issues/64171

Reviewed By: cor3ntin, balazske, aaron.ballman

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

(cherry picked from commit 91c4b5550ecfbb7afe7275c341b73a6d3a1bbd78)

[clang-format] Fix braced initializer with templated base class

Fixes #64134.

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

(cherry picked from commit 400da115c58ae19445cfdc871a3f559f160fc5c6)

[clang][ExprConstant] Fix crash on uninitialized base class subobject

This patch fixes the reported regression caused by D146358 through adding notes about an uninitialized base class when we diagnose uninitialized constructor.

This also changes the wording from the old one in order to make it clear that the uninitialized subobject is a base class and its constructor is not called.
Wording changes:
BEFORE: `subobject of type 'Base' is not initialized`
AFTER: `constructor of base class 'Base' is not called`

Fixes https://github.com/llvm/llvm-project/issues/63496

Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D153969

Reland "[clang-repl] Adapt to the recent dylib-related changes in ORC."

Original commit message:"

ORC splits into separate dylibs symbols coming from the process and symbols
materialized in the Jit. This patch adapts intent of the existing interface and
adds a regression test to make sure both Jit'd and compiled symbols can be found.

Differential revision: https://reviews.llvm.org/D159115
"

This patch disables the test statement on windows as it seems we might have a
bug in the way we model dllimports.

(cherry picked from commit 452cb7f20bc7b976eb6fec4ac9f2d902f4175c08)

[X86][BF16] Lower FP_EXTEND for vector types under AVX512BF16

Fixes #64460

Reviewed By: RKSimon, skan

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

(cherry picked from commit 6688701497ea8e562b769bdb154a40f4a1099abb)

[Tests][ConstraintElim] autogen newly-added case in large-constant-ints.ll (NFC)

I forgot to do this in 66ec5df3a7f33366455d50769e4e878544becea6 / https://reviews.llvm.org/D158810.

Since this is testing for an assertion failure, the test checks don't matter, but we might as well avoid unnecessary churn the next time someone modifies this test.

(cherry picked from commit df112cba034eefb86d0e92e18518f5e944d58c37)

[ConstraintElim] fix crash with large constants in mul nsw

Another case of https://github.com/llvm/llvm-project/issues/55085.

The added test would trip an assertion due to calling `getSExtValue()` on a value that doesn't fit in int64_t.

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

(cherry picked from commit 66ec5df3a7f33366455d50769e4e878544becea6)

[llvm-exegesis] Use mmap2 when mmap is unavailable to fix riscv32 build

Some 32-bit architectures don't have mmap and define mmap2 instead.
E.g. on riscv32 we may get

```
| /mnt/b/yoe/master/build/tmp/work-shared/llvm-project-source-17.0.0-r0/git/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:1116:19: error: use of undeclared identifier 'SYS_mmap'
|  1116 |   generateSyscall(SYS_mmap, MmapCode);
|       |                   ^
| /mnt/b/yoe/master/build/tmp/work-shared/llvm-project-source-17.0.0-r0/git/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:1134:19: error: use of undeclared identifier 'SYS_mmap'
|  1134 |   generateSyscall(SYS_mmap, GeneratedCode);                                                                                                                                       |       |                   ^
| 1 warning and 2 errors generated.
```

Co-Authored-By: Fangrui Song <i@maskray.me>
Differential Revision: https://reviews.llvm.org/D158375

(cherry picked from commit 01a92f06f23585f15b3e83b7c378d0df2d91e06b)

Fix up release note; NFC

[llvm-rc] Continue to use Argv[0] to resolve executable path

In internal google builds, MainExecPath doesn't go to the directory with `clang`.
Fall back to using Argv0 if MainExecPath doesn't find any clangs.

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

(cherry picked from commit e4eb8d97e8afcb879dc5cd0da7a937dbb26fbf12)

[Driver,X86] Ignore -mfpmath= for assembler input

Some options are only claimed in AddX86TargetArgs/etc (called by
Clang::RenderTargetOptions).
For assembler input, `Add*TargetArgs` is not called. If an option is
unclaimed, it either leads to a -Wunused-command-line-argument warning
or an error (if `TargetSpecific` is set)
```
// clang '-###' --target=x86_64 -mfpmath=sse -c a.s
clang: error: unsupported option '-mfpmath=sse' for target 'x86_64'
```

For -mfpmath=, it's actually claimed by RenderFloatingPointOptions,
which should be moved to AddARMTargetArgs/AddX86TargetArgs later
(non-AArch32-non-x86 targets give a frontend error).
This change is localized and similar to D153691, for release/17.x
backporting.

Fix https://github.com/llvm/llvm-project/issues/65023

Reviewed By: thesamesam

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

(cherry picked from commit 081afa3d04a4bc0d43c62b5b0e5a84f86a8a70ec)

Revert "[clang] Set FP options in Sema when instantiating CompoundStmt"

This reverts commit f1d5ea362577a8a1b5fafe775cf82a449daa3b07.

Revert "[clang] Run test for concrete target"

This reverts commit e54f48384bb213f2c204c74d4e7e08a13904a9d6.

[Driver] Add PIE support on Solaris

`clang` currently lacks PIE support on Solaris.  This patch fixes this,
also linking with `crtbeginS.o` and `crtendS.o` for `-pie` and `-shared`.

Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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

(cherry picked from commit 62945bb811169ffac7cf22c64b6dd3a3ad8d38f0)

[libc++] Fix GNU/Hurd build

GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete.

Reviewed By: #libc, Mordante

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

(cherry picked from commit 1cfcc36812ff7857567f7c729c22ae0e2be0fb3a)

[AArch64] Check opcode before trying to extract register from operand

When matching FNEG patterns for the MachineCombiner we need to check for
opcodes first, before trying to extract a register from an operand.
Otherwise handling of instructions with non-register operands causes the
compiler to crash.

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

(cherry picked from commit 979e8ae4fce64546c65d24864eedd8165bc9787b)

[PowerPC] Exclude frexp(long double) on linux

PowerPC on linux currently don't have support for lowering long double for
frexp().  Removing the tests until implementation is provided.

Reviewed By: #libc, amyk, Mordante

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

(cherry picked from commit 5adac8bebcf26841c1d87227c5043af83a9ef94b)

[BOLT][Instrumentation] Add test for append-pid option

Reviewed By: rafauler

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

(cherry picked from commit dfc759929644ed1ea3224ab30e1086f7acc60da6)

[BOLT][Instrumentation] Fix indirect call profile in PIE

Because indirect call tables use static addresses for call sites, but pc
values recorded by runtime may be subject to ASLR in PIE, we couldn't
find indirect call descriptions by their runtime address in PIE. It
resulted in [unknown] entries in profile for all indirect calls. We need
to substract base address of .text from runtime addresses to get the
corresponding static addresses. Here we create a getter for base address
of .text and substract it's return value from recorded PC values. It
converts them to static addresses, which then may be used to find the
corresponding indirect call descriptions.

Reviewed By: rafauler

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

(cherry picked from commit a86dd9ae60662cfe9f9fb709a33c71d6fec66dfb)

[NFC] [C++20] [Coroutines] Mention the side effect of a fix may bring regressions

The fix we sent for https://github.com/llvm/llvm-project/issues/56301
may bring performance regressions. But we didn't mention it in the
ReleaseNotes so that users may get confused. e.g,
https://github.com/llvm/llvm-project/issues/64933. So this patch
mentions the possible side effect and the potential solutions in
https://github.com/llvm/llvm-project/issues/64945 to avoid
misunderstandings.

[C++20] [Coroutines] Mark await_suspend as noinline if the awaiter is not empty

Close https://github.com/llvm/llvm-project/issues/56301
Close https://github.com/llvm/llvm-project/issues/64151

See the summary and the discussion of https://reviews.llvm.org/D157070
to get the full context.

As @rjmccall pointed out, the key point of the root cause is that
currently we didn't implement the semantics for '@llvm.coro.save' well
("after the await-ready returns false, the coroutine is considered to be
suspended ") well.
Since the semantics implies that we (the compiler) shouldn't write the
spills into the coroutine frame in the await_suspend. But now it is possible
due to some combinations of the optimizations so the semantics are
broken. And the inlining is the root optimization of such optimizations.
So in this patch, we tried to add the `noinline` attribute to the
await_suspend call.

Also as an optimization, we don't add the `noinline` attribute to the
await_suspend call if the awaiter is an empty class. This should be
correct since the programmers can't access the local variables in
await_suspend if the awaiter is empty. I think this is necessary for the
performance since it is pretty common.

Another potential optimization is:

    call @llvm.coro.await_suspend(ptr %awaiter, ptr %handle,
                                  ptr @awaitSuspendFn)

Then it is much easier to perform the safety analysis in the middle
end.
If it is safe to inline the call to awaitSuspend, we can replace it
in the CoroEarly pass. Otherwise we could replace it in the CoroSplit
pass.

Reviewed By: rjmccall

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

[libc++][Modules] locale fails to compile with clang modules when _LIBCPP_LOCALE__L_EXTENSIONS is undefined

When `__locale_dir/locale_base_api/locale_guard.h is` compiled independently, as it is when it's in its own clang module, it fails to compile due to `locale_t` being undefined. It needs to include `__locale` to get that, instead of just `clocale`.

Reviewed By: ldionne, #libc

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

(cherry picked from commit 6021c78fe55e3c4d3e073710bfe279c6a28566d4)

[libc++] Increase the constexpr steps limit on some `bitset` tests.

Prevent these tests from failing on some platforms (the number of
constexpr steps increased by https://reviews.llvm.org/D154860).

(cherry picked from commit 91876eab93a9f0ef29a339ed99bdb1c8ed1e85c6)

[libc++][ranges] Fix `ranges::to` test.

- Make a test for an internal concept libc++-only;
- Make sure that `size` and `capacity` in a test container return the
  same type on all platforms.

(cherry picked from commit 8b9a98661b780a5b50d1d6a1f822d25e0c454382)

[libc++][Modules] Simplify the __std_clang_module header generation

Post review feedback on D157364. Don't section the __std_clang_module header by macro, put the headers in alphabetical order and repeat the macro guards. Restore header_information.header_restrictions.

Reviewed By: ldionne, #libc

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

# Conflicts:
# libcxx/utils/libcxx/header_information.py

[libc++][Modules] Generate the __std_clang_module header

Use header_information to generate the __std_clang_module header. Instead of using lit_header_restrictions like the manually written header did, make a new header_include_requirements to codify what can be included rather than what can be fully tested.

Reviewed By: Mordante, #libc

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

# Conflicts:
# libcxx/utils/libcxx/header_information.py

[libc++][Modules] Remove unnecessary `requires` from the module map

Top level modules don't need `requires` because they're only built when their headers are included.

Reviewed By: ldionne, Mordante, #libc

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

[libc++] Move header_information.py up from tests

I need to use header_information.py in a generator script that isn't for tests in an upcoming change. Move it up a level so that it's in utils/libcxx instead of utils/libcxx/tests.

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

# Conflicts:
# libcxx/test/libcxx/system_reserved_names.gen.py

[libc++] Fix problems with GCC 13 and switch to it in the CI

Reviewed By: #libc, #libc_abi, Mordante

Spies: arphaman, Mordante, libcxx-commits, arichardson

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

Fix regression of D157680

Test cases in D157680 should be target specific, but miss some limit, add them back to make buildbot pass.

Reviewed By: skan, Hahnfeld

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

Fix ODS verifier emission for DerivedAttr when Properties are enabled

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

Fix canonicalizer to copy the entire GreedyRewriteConfig instead of selected fields

It is surprising for the user that only some fields were honored.

Also make the FrozenRewritePatternSet a shared_ptr<const T>.

Fixes #64543

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

Fix MSAN error: use of unitialized value when hashing the MLIR pass manager (NFC)

Fix MLIR pass manager initialization: hash the pass pipeline to detect when initialization is needed

The current logic hashes the context to detect registration changes and re-run
the pass initialization. However it wasn't checking for changes to the
pipeline, so a pass that would get added after a first run would not be
initialized during subsequent runs.

Reviewed By: Mogball

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

Fix some missing fully qualified namespaces in MLIR TableGen generator

Using properties would break when a dialect isn't in the mlir namespace

Fix MLIR build failure: error: no member named 'getValue' in 'mlir::OptionalParseResult'

Fix #63072

Finish renaming getOperandSegmentSizeAttr() from `operand_segment_sizes` to `operandSegmentSizes`

This renaming started with the native ODS support for properties, this is completing it.

A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
 properties.odsOperandSegmentSizes
reverts back to:
 properties.operandSegementSizes

The ODS prefix was creating divergence between all the places and make it harder to
be consistent.

Reviewed By: jpienaar

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

[clang] Run test for concrete target

The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.

(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)

[clang] Set FP options in Sema when instantiating CompoundStmt

When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.

To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.

This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).

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

(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)

clang: Fix x86-no-gather-no-scatter.cpp on macOS after 993bdb047c90e9

On macOS, files are usually below `/Users/...` and clang-cl treats
that as the `/U` flag followed by something instead of as a path.
Put `--` in front of `%s` to make it treat it as a patch, like in
all other tests.

The failure without this change:

    x86-no-gather-no-scatter.cpp:4:14: error: NOGATHER: expected string not found in input
    // NOGATHER: "-target-feature" "+prefer-no-gather"
                 ^
    <stdin>:5:44: note: possible intended match here
    clang: warning: 'x86-no-gather-no-scatter.cpp' treated as the '/U' option [-Wslash-u-filename]
                                               ^

(cherry picked from commit 547ee1c81fceaabcb7064ed525f11f9e94083f56)

[MachineLICM][WinEH] Don't hoist register reloads out of funclets

This fixes https://github.com/llvm/llvm-project/issues/60766

With MSVC style exception-handling (funclets), no registers are
alive when entering the funclet so they must be reloaded from the
stack.  MachineLICM can sometimes hoist such reloads out of the
funclet which is not correct, the register will have been clobbered
when entering the funclet.  This can happen in any loop that
contains a try-catch.

This has been tested on x86_64-pc-window-msvc.  I'm not sure if
funclets work the same on the other windows archs.

Reviewed By: rnk, arsenm

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

(cherry picked from commit 917574d5d8beacbefab4d0e6469dac5b50117832)

[BOLT][Instrumentation] Keep profile open in WatchProcess

When a binary is instrumented with --instrumentation-sleep-time and
instrumentation-wait-forks options and lauched, the profile is
periodically written until all the forks die. The problem is that we
cannot wait for the whole process tree, and we have no way to tell when
it's safe to read the profile. Hovewer, if we keep profile open
throughout the life of the process tree, we can use fuser to determine
when writing is finished.

Reviewed By: rafauler

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

(cherry picked from commit a799298152e3ef08b4919cdaac7a614f7cca9bc6)

[Coroutines] [CoroElide] Don't think exceptional terminator don't leak coro handle unconditionally any more

Close https://github.com/llvm/llvm-project/issues/59723.

The fundamental cause of the above issue is that we assumed the memory
of coroutine frame can be released by stack unwinding automatically
if the allocation of the coroutine frame is elided. But we missed one
point: the stack unwinding has different semantics with the explicit
coroutine_handle<>::destroy(). Since the latter is explicit so it shows
the intention of the user. So we can blame the user to destroy the
coroutine frame incorrectly in case of use-after-free happens. But we
can't do so with stack unwinding.

So after this patch, we won't think the exceptional terminator don't
leak the coroutine handle unconditionally. Instead, we think the
exceptional terminator will leak the coroutine handle too if the
coroutine is leaked somewhere along the search path.

Concretely for C++, we can think the exceptional terminator is not
special any more. Maybe this may cause some performance regressions.
But I've tested the motivating example (std::generator). And on the
other side, the coroutine elision is a middle end opitmization and not
a language feature. So we don't think we should blame such regressions
especially we are correcting the miscompilations.

(cherry picked from commit 7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f)

[CGCall][RISCV] Handle function calls with parameter of RVV tuple type

This was an oversight in D146872, where function calls with tuple type
was not covered. This commit fixes this.

Reviewed By: craig.topper

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

(cherry picked from commit 39a41c8905618fc942100630b4ea37f0cb95e786)

[OpenMP][OMPT] Fix `target enter data` callback ordering & reported device num

This patch fixes: https://github.com/llvm/llvm-project/issues/64738
We observed multiple issues, primarily that the `DeviceId` was reported as -1
in certain scenarios. The reason for this is simply that the device is not
initialized at that point. Hence, we need to move the RAII object creation just
after the `checkDeviceAndCtors`, closer to the actual call we want to observe.

This also solves an odering issue where one `target enter data` callback would
be executed before the `Init` callback.
Additionally, this change will also fix that the callbacks corresponding to
`enter / exit data` and `update` in conjunction with `nowait` would not result
in the emission of an OMPT callback.

Added a testcase to cover initialized device number and `omp target` constructs.

Reviewed By: dhruvachak

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

(cherry picked from commit 57f0bdc8fb1e66d4ed9cfb57f1ef699eefd99646)

[OpenMP][OMPT] Fix reported target pointer for data alloc callback

This patch fixes: https://github.com/llvm/llvm-project/issues/64671
DataOp EMI callbacks would not report the correct target pointer.
This is now alleviated by passing a `void**` into the function which
emits the actual callback, then evaluating that pointer.

Note: Since this is only done after the pointer has been properly
updated, only `endpoint=2` callbacks will show a non-null value.

Reviewed By: dhruvachak, jdoerfert

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

(cherry picked from commit 41f3626f8b300cef24c06d9e8b7cf53029a4330a)

[RISCV] Check type size for lax conversions between RVV builtin types and VectorType::RVVFixedLengthDataVector.

This code was copied from SVE and modified for RVV. For SVE, there
is only one size for builtin types so they didn't need to check
the size. For RVV, due to LMUL there are 7 different sizes of builtin
types so we do need to check the size.

I'm not sure we should have lax vector conversions at all for RVV.
That appears to be contributing to https://github.com/llvm/llvm-project/issues/64404

This patch at least fixes the obvious correctness issue.
This should be backported to LLVM 17.

Reviewed By: jacquesguan

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

(cherry picked from commit 33af2f131db71a18aefc5469129540e2097a537f)

[compiler-rt] Use .globl for FreeBSD/NetBSD interceptor wrappers

On FreeBSD and NetBSD we don't use .weak due to differing semantics.
Currently we end up using no directive, which gives a local symbol,
whereas the closer thing to a weak symbol would be a global one. In
particular, both GNU and LLVM toolchains cannot handle a GOT-indirect
reference to a local symbol at a non-zero offset within a section on
AArch64 (see https://github.com/ARM-software/abi-aa/issues/217), and so
interceptors do not work on FreeBSD/arm64, failing to link with LLD.
Switching to .globl both works around this bug and more closely aligns
such non-weak platforms with weak ones.

Fixes https://github.com/llvm/llvm-project/issues/63418

Reviewed By: MaskRay

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

(cherry picked from commit 7e1afab1b1821550c5f8d0d6a50636236fa02e2c)

Revert "[XCOFF][AIX] Peephole optimization for toc-data."

This reverts commit 5e28d30f1fb10faf2db2f8bf0502e7fd72e6ac2e.

(cherry picked from commit cef56b9318e37e9c47fd356c76c9da522bc8c122)