This brings the unmodified SipHash reference implementation:
  https://github.com/veorq/SipHash
which has been very graciously licensed under our llvm license
(Apache-2.0 WITH LLVM-exception) by Jean-Philippe Aumasson.

SipHash is a lightweight hash function optimized for speed on short
messages.  We use it as part of the AArch64 ptrauth ABI (in arm64e and
ELF PAuth) to generate discriminators based on language identifiers and
mangled names.

This commit brings the reference implementation (siphash.c@f26d35e)
unmodified, as SipHash.cpp.

Next, we will integrate it properly into libSupport, with a wrapping API
suited for the ptrauth use-case.

Previously the `type_traits` target manually listed all of the type
traits files. This patch replaces that with a glob to make the build
simpler.

PR #92983 accidentally changed the buffer allocation in
`llvm::WriteBitcodeToFile` to be allocated on the stack, which is
problematic given it's a large-ish buffer (256K)

Summary:
These tools need to be built before we can do the library creation
stage. If they are generated in the same build then this is not
guaranteed so we should add explicit dependencies.

This patch introduces a new ExtractFromEnd VPInstruction opcode to
extract the value of a FOR for users outside the loop (i.e. in the
scalar loop's exits). This moves the first part of fixing first order
recurrences to VPlan, and removes some additional code to patch up
live-outs, which is now handled automatically.

The majority of test changes is due to changes in the order of which the
extracts are generated now. As we are now using VPTransformState to
generate the extracts, we may be able to re-use existing extracts in the
loop body in some cases. For scalable vectors, in some cases we now have
to compute the runtime VF twice, as each extract is now independent, but
those should be trivial to clean up for later passes (and in line with
other places in the code that also liberally re-compute runtime VFs).

PR: https://github.com/llvm/llvm-project/pull/93395

Some applications like to use a CPP-style #include directive to pull in
a common list of arguments, dummy arguments, or COMMON block variables
after a free-form & line continuation marker. This works naturally with
compilers that run an actual cpp pass over the input before doing
anything specific to Fortran, but it's a case that I missed with this
integrated preprocessor.

Most Fortran compilers accept "doubled operators" as a language
extension. This is the use of a unary '+' or '-' operator that is not
the first unparenthesized operator in an expression, as in 'x*-y'.

This compiler has implemented this extension, but in a way that's
different from other compilers' behavior. I interpreted the unary
'+'/'-' as a unary operator in the sense of C/C++, giving it a higher
priority than any binary (dyadic) operator.

All other compilers with this extension, however, give a unary '+'/'-' a
lower precedence than exponentiation ('**'), a binary operator that
C/C++ lacks. And this interpretation makes more sense for Fortran,
anyway, where the standard conforming '-x**y' must mean '-(x**y)'
already.

This patch makes 'x*-y**z' parse as 'x*-(y**z)', not 'x*(-y)**z)', and
adds a test to ensure that it does.

This is needed for the allocator implementation for malloc.

Summary:
You can build the GPU libc support in projects mode. There were some
issues with it not finding the correct binaries. This patch fixes that.

[clang][Sema] Don't issue -Wcast-function-type-mismatch for enums with a matching underlying type (#87793)

Enums are passed as their underlying integral type so they're ABI compatible if the size matches.
Useful with C APIs that pass user-controlled values to callbacks that can be made type safe by using enumerations (e.g. GStreamer).

Discovered internally in some code after 999d4f84.

Add patterns to label NVPTX backend related changes automatically.

Call InsertNewInstWith() instead of InsertNewInstBefore() when creating
"store to null" instruction

This means that CI won't have to hardcode these.

If a delete is pending on the file queried for status, a misleading
`permission_denied` error code will be returned (this is the correct
mapping of the error set by GetFileAttributesW). By querying the
underlying NTSTATUS code via ntdll's RtlGetLastNtStatus, this case can
be disambiguated. If this underlying error code indicates a pending
delete, fs::status will return a new `pending_delete` error code to be
handled by callers

Fixes #89137

Reverts llvm/llvm-project#94022

This is not actually valid bazel syntax. Buildbot failure: https://buildkite.com/llvm-project/upstream-bazel/builds/99430#018fdf11-6865-4d5d-be8e-7bfab59e3cd8

Summary:
The runtimes builds create separate projects. Normally these use
`LLVM_EANBLE_RUNTIMES`. However, we can also use `LLVM_RUNTIME_TARGETS`
and `RUNTIMES_<target>_LLVM_ENABLE_RUNTIMES` to enable them. Currently,
if `LLVM_RUNTIME_TARGETS` isn't specified this is completely ignored.
This patch fixes the behavior so we can only specify the cross-compiling
versions.

See #94000 for a report of a downstream failure, this fixes it.

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations

):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>

[cmake] Pass -resource-dir to external projects as CMAKE_<LANG>_FLAGS_INIT instead of as a force override (#87330)

It's useful to use toolchain files for configuring runtimes builds.
Setting `CMAKE_<LANG>_FLAGS` is however forceful and precludes initialization from the _INIT variant meant to be set by toolchains.
The toolchain file still needs to append instead of just setting and be idempotent (`include_guard()`), but this way at least a special toolchain to account for LLVM won't be required.

After #94055 this test failed on ARM/AArch64-hosted Windows, but it's
not clear why.

[lldb][test][NFC] TestBreakpointSetRestart.py: split up assertion to determine which check specifically fails in CI

This test consistently fails on the public macOS ASAN CI (and isn't
reproducible locally):
```
FAIL: test_breakpoint_set_restart_dwarf
(TestBreakpointSetRestart.BreakpointSetRestart)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1756, in test_method
    return attrvalue(self)
  File
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 150, in wrapper
    return func(*args, **kwargs)
  File
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/test/API/functionalities/breakpoint/breakpoint_set_restart/TestBreakpointSetRestart.py",
line 36, in test_breakpoint_set_restart
    self.assertTrue(bp.IsValid() and bp.GetNumLocations() == 1,
VALID_BREAKPOINT)
AssertionError: False is not true : Got a valid breakpoint
```

From this error we're not quite sure what about the breakpoint here is
the problem.

This patch splits up the assertion to narrow down the issue.

This argument allows to specify the path to make which is used by
LLDB API tests to compile test programs.
It might come in handy for setting up cross-platform remote runs of API tests on Windows host.

It can be used to override the make path of LLDB API tests using `LLDB_TEST_USER_ARGS` argument:
```
cmake ...
-DLLDB_TEST_USER_ARGS="...;--make;C:\\Path\\to\\make.exe;..."
...
```

PR #77948 mistakenly rejected floating-point representation with a
leading decimal point, e.g. ".5".

This PR fixes the regression mentioned in
https://github.com/llvm/llvm-project/pull/77948#issuecomment-2141740346.

This commit fixes https://github.com/llvm/llvm-project/issues/88896 by
passing LangOpts from the CompilerInstance to
DependencyScanningWorker so that the original LangOpts are
preserved/respected.
This makes for more accurate parsing/lexing when certain language
versions or features specific to versions are to be used.

Lower select rank according to [assumed-rank lowering design
doc](https://github.com/llvm/llvm-project/blob/main/flang/docs/AssumedRank.md).

The construct is lowered using fir.box_rank and fir.select_case
operation and, for the non pointer/allocatable case, a
fir.is_assumed_size + conditional branch before the select_case to deal
with the assumed-size case.

The way the CFG logic is generated, apart from the extra conditional
branch for assumed-size, is similar to what is done for SELECT CASE
lowering, hence the sharing of the construct level visitor. 
For the CFG parts. The main difference is that we need to keep track of
the selector to cook it and map it inside the cases (hence the new
members of the ConstructContext).

The only TODOs left are to deal with the RANK(*) case for polymorphic
entities and PDTs. I will do the polymorphic case in a distinct patch,
this patch has enough content.

Fortran::evaluate::IsSimplyContiguous change  is needed to avoid generating
copy-in/copy-out runtime calls when passing the RANK(*) associating
entity to some implicit interface.

The current test is not really correct because the mask is set to
0xffffffff
even if it is on an AMDGPU whose wavefront size is 64. Besides,
`__AMDGCN_WAVEFRONT_SIZE` is not set on host compilation so the
verification
happens to work.

Lower to IsAssumedSize runtime call in `--fir-assumed-rank-op` pass.

Noticed while triaging the failures on #93673

FirstCand is a reference to RepeatedSequenceLocs[0]. However, that
vector is being modified a lot throughout the function, including one
place that reassigns the whole vector. I'm not sure whether this can
really happen in practice, but it doesn't seem unlikely that this could
lead to a use-after-free.

Avoid this by directly using RepeatedSequenceLocs[0] at the start of the
function (as a lot of other places already do) and only creating
FirstCand at the end where no more modifications take place.

Replace argmemonly readonly with memory(argmem: read).

Particular example that lead to this is a very long chain of
`UsingShadowDecl`s that we hit in our codebase in generated code.

To avoid that, check for stack exhaustion when deserializing the
declaration. At that point, we can point to source location of a
particular declaration that is being deserialized.

reorganize the PPCInstrP10.td based on comment
https://github.com/llvm/llvm-project/pull/92543#discussion_r1610908205
 
The instructions or patterns defined by same predicates are currently
placed at several different locations , They will be reorganized into
same group based on these predicates in the patch.

The std::min behaves like 'a<b?a:b', which does not match
libstdc++/libc++ behavior like 'b<a?b:a' when input is NaN.

Make it consistent with libstdc++/libc++.

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

Fixes: https://github.com/ROCm/HIP/issues/3502

As noted in
https://github.com/llvm/llvm-project/pull/93796#issuecomment-2142752336,
a better way to teach RISCVInsertVSETVLI to work without LiveIntervals
is to set VNInfo to nullptr and teach the various methods to handle it.
We should try that approach first, so we no longer need this pre-commit
patch.

This reverts commit 4b4d3665.

This reduce the time complexity of the main loop of `findCandidates()`
method from $O(n^2)$ to $O(n \log n)$.

For small $n$, the modification does not regress the build time, but it
helps significantly when $n$ is large.

For one application, this reduces the runtime of the main loop from 120
seconds to 28 seconds.

This is the first commit for an enhanced version of machine outliner --
see
[RFC](https://discourse.llvm.org/t/rfc-enhanced-machine-outliner-part-1-fulllto-part-2-thinlto-nolto-to-come/78732).

Fix typos in AGGRESIVE-->AGGRESSIVE + WAYAGGRESIVE->WAYAGGRESSIVE

This also exposed an issue that the WAYAGGRESSIVE run removed a block entirely, so the LABEL check was silently failing.

Noticed while triaging the failures on #93673