For alias templates, the way we construct their aggregate deduction guides is
not following the standard way. We should do the same thing as we do for
implicit deduction guides.

Refactor: Extract the core deduction-guide construction implementation from DeclareImplicitDeductionGuidesForTypeAlias

We move the core implementation to a dedicate function, so that it can
be reused in other places.

I'm taking yet another swing at getting these tests going, on the
hypothesis that the problems with buildbots & whatnot are because
they're not configured with CURL support, which I've confirmed would
cause the previous tests to fail. (I have no access to an ARM64 linux
system, but I did repro the failure on MacOS configured without CURL
support)

So, the only difference between this diff and
[previous](https://github.com/llvm/llvm-project/pull/85693)
[diffs](https://github.com/llvm/llvm-project/pull/87676) that have
already been approved is that I've added a condition to the tests to
only run if Debuginfod capabilities should be built into the binary. I
had done this for these tests when they were [Shell
tests](https://github.com/llvm/llvm-project/pull/79181

) and not API
tests, but I couldn't find a direct analog in any API test, so I used
the "plugins" model used by the intel-pt tests as well.

---------

Co-authored-by: Kevin Frei <freik@meta.com>

This PR fixes bugs in HLSL floating conversions. HLSL always has `half`,
`float` and `double` types, which promote in the order:

`half`->`float`->`double`

and convert in the order:

`double`->`float`->`half`

As with other conversions in C++, promotions are preferred over
conversions.

We do have floating conversions documented in the draft language
specification (https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf
[Conv.rank.float]) although the exact language is still in flux
(https://github.com/microsoft/hlsl-specs/pull/206).

Resolves #81047

Currently the code uses FunctionSamples::getCallSiteIdentifier which
will sometimes incorrectly guess that FSAFDO discriminators are probe
based and will convert them incorrectly.

This change doesn't affect builds which don't use FSAFDO, it only fixes
sample profile matching with FS discriminators.

The test for this is manually updated to use discriminator value 15,
which is a perfectly valid base discriminator in the FS world, but
satisfies `isPseudoProbeDiscriminator`, so
`getBaseDiscriminatorFromDiscriminator` will incorrectly extract the
probe index from it.

Note: this change only affects how the base discriminators will be
extracted when doing stale profile matching in the IR-level sample
profile loader. It doesn't add stale profile matching to the MIR-level
FS profile loader pass.

[RISCV] Detect empty extension name after parsing MajorVersion in parseNormalizedArchString. (#90790)

If the string is just a version, we will end up adding an empty string
as an extension which crashes in the compare function for the std::map.

This reverts commit 6195e228.

Addressing post-commit review on #89807

Reverted following probably-causing failures on some clang buildbots:
  https://lab.llvm.org/buildbot/#/builders/245/builds/24037

This reverts commit a1262254.

Previously we only rejected upper case characters. We should instead
reject anything except lower case, numbers, and underscore. Other
characters will likely confuse the extension sorting.

Previously each single use producer would be marked with a
"S_SINGLEUSE_VDST 1" instruction. This patch adds support for
larger immediates that encode multiple single use producers into
one S_SINGLEUSE_VDST instruction.

This caused an assertion failure for the following input:

  __SVInt32_t bar(__SVInt32_t x);

  void foo(__SVInt32_t x) {
    return bar(x);
  }

Implement the matching distance as described here:
https://docs.nvidia.com/hpc-sdk/archive/24.3/compilers/cuda-fortran-prog-guide/index.html#cfref-var-attr-unified-data

Generic resolved to the smallest distance.

Some minor fixes to clean up tabs and language in code documentation.

  - Add m_CondCode to match the ISD::CondCode value from CondCodeSDNode
  - Add m_NoneOf combinator
  - m_SExt now recognizes sext_inreg

Fixes #48758

These are now passing on AArch64 FreeBSD 14.

As the summary suggests, the code incorrectly assumes that it can use
NEON or SVE instructions to implement an interleaved load/store
operation, even when both features are unavailable in the selected
runtime mode.

Fixes the broken tests in the original commit:
  2f01fd99

This will probably break some downstream tools that don't already handle
debug records. If your downstream code breaks as a result of this
change, the simplest fix is to convert the module in question to the old
debug format before you process it, using
`Module::convertFromNewDbgValues()`. For more information about how to
handle debug records or about what has changed, see the migration
document:
  https://llvm.org/docs/RemoveDIsDebugInfo.html

This reverts commit 00821fed.

https://github.com/llvm/llvm-project/pull/84173 added uses of std::labs
on an int64_t which leads to this warning on Arm 32 bit:
```
/home/david.spickett/llvm-project/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:16655:12: warning: absolute value function 'labs' given an argument of type 'long long' but has parameter of type 'long' which may cause truncation of value [-Wabsolute-value]
    return std::labs(Imm / 4) <= 16;
           ^
/home/david.spickett/llvm-project/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:16655:12: note: use function 'std::abs' instead
    return std::labs(Imm / 4) <= 16;
           ^~~~~~~~~
           std::abs
```

Since int64_t is "long long" on Arm, not "long".

Use std::abs instead since it has versions for "long" and "long long",
we'll pick up the right one at compile time
(https://en.cppreference.com/w/cpp/numeric/math/abs).

The large size doesn't add anything here, at least not with the
test in its current form.

If openmp is on the LLVM_ENABLE_PROJECTS list and
offload is on LLVM_ENABLE_RUNTIMES list when using
CLANG_ENABLE_BOOTSTRAP, then the runtimes will be
configured before the openmp project. This will throw a cannot find
libomp.so dependency error. Add omp as a dependency when this is the
case. Update
offload cmake for detection of LIBOMP_HAVE_VERSION_SCRIPT.

LazyAtomicPointer.h:36:49: warning: implicit conversion from 'unsigned long long'
to 'uintptr_t' (aka 'unsigned int') changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
  static constexpr uintptr_t getBusy() { return -1ULL; }

On 32 bit Arm ULL is an unsigned long long which is 8 bytes, but
uintptr_t is 4 bytes. Instead of using a value, use the macro
UINTPTR_MAX that will be the correctly sized value.

I tried also printing the -march they correspond to, but it seemed
overly verbose and caused line wraps. It might be better if we remove
the versions numbers from the string or did a more intelligent line
wrap.

This reverts commit 427c5bfd.

Before this commit the the checker alpha.security.taint.TaintPropagation always reported warnings when the size argument of a memcpy-like or malloc-like function was tainted. However, this produced false positive reports in situations where the size was tainted, but correctly performed bound checks guaranteed the safety of the call.
 
This commit removes the rough "always warn if the size argument is tainted" heuristic; but it would be good to add a more refined "warns if the size argument is tainted and can be too large" heuristic in follow-up commits. That logic would belong to CStringChecker and MallocChecker, because those are the checkers responsible for the more detailed modeling of memcpy-like and malloc-like functions. To mark this plan, TODO comments are added in those two checkers.
 
There were several test cases that used these sinks to test generic properties of taint tracking; those were adapted to use different logic.
 
As a minor unrelated change, this commit ensures that strcat (and its wide variant, wcsncat) propagates taint from the first argument to the first argument, i.e. a tainted string remains tainted if we concatenate it with another string. This change was required because the adapted variant of multipleTaintedArgs is relying on strncat to compose a value that combines taint from two different sources.
 

All the compilers we support implement those macros or builtins, so it's
not useful to have a fallback to 0 when they're not implemented.

Use structured bindings and similar.

Performing `instSimplify` while cloning is unsafe due to incomplete
remapping (as reported in #87534). Ideally, `instSimplify` ought to
reason on the updated newly-cloned function, after returns have been
rewritten and callee entry basic block / call-site have been fixed up.
This is in contrast to `CloneAndPruneIntoFromInst` behaviour, which
is inherently expected to clone basic blocks, with pruning on top of
– if any –, and not actually fixing up returns / CFG, which should be
up to the Inliner. We may solve this by letting `instSimplify` work on
the newly-cloned function, while maintaining old function attributes,
so as to avoid inconsistencies between the yet-to-be-solved return
type, and new function ret type attributes.

Original commit: a61f9fe3

Multiple 2-stage buildbots were reporting failures. These issues have been
addressed separately.

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

It requires amdgpu registered target.

First round of Sema checks were run at initial parsing step. Creating a
new BinaryOperator instance (with the re-built LHS or RHS) will trigger
another round of Sema checks, which can lead to duplicate diagnostic
warning messages.

All we want here is to replace the LHS or RHS with a NonOdrUse version.
Don't create a new BinaryOperator, but simply replace the LHS or RHS of
the given BinaryOperator.

Fixes #45783

This PR is to fix issue #88889 . 
Because the type of an actual argument of an array expression of
character has type of `hlfir::ExprType`, we need to transform it to
`fir::SequenceType` before calling `getBoxTypeWithNewShape`.
Calling `hlfir::ExprType::getShape` inside of `getBoxTypeWithNewShape`
will introduce a circular dependency on FIRDialect and HLFIRDialect
libraries.