[Clang] Fix ResolveConstructorOverload to not select a conversion function if we are going use copy elision

ResolveConstructorOverload needs to check properly if we are going to use copy
elision we can't use a conversion function.

This fixes:

https://github.com/llvm/llvm-project/issues/39319
https://github.com/llvm/llvm-project/issues/60182
https://github.com/llvm/llvm-project/issues/62157
https://github.com/llvm/llvm-project/issues/64885
https://github.com/llvm/llvm-project/issues/65568

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

We'd like to make various instrprof globals large to make them not
contribute to relocation pressure since there are no direct accesses
to them in the module.

Similar to what was done for asan_globals in #74514.

This affects the __llvm_prf_vals, __llvm_prf_vnds, and __llvm_prf_names
sections.

If the 'directive name' is a special token instead of an identifier, we
end up asserting.  This fixes that.

This should make it easier to get better output when wchar_t tests fail.
The code is based on the Unicode transcoding in `<format>`.

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

…arse conv.

Fix forward for #74862

Required for torch-mlir.
Cf. llvm/torch-mlir#2604 "Implement torch.aten.acos".

Use %t in output file name as %T is non-unique.

Fix #74258
This is a reland of #74837, the error went unnoticed because it compiles
fine on
clang-16 but not on clang-12 which is the version used on the buildbots.

The fix was to explicitly initialize `BigInt` variables in `constexpr`
operations: `BigInt<Bits, Signed> result(0);` instead of `BigInt<Bits,
Signed> result;`

Add builtin: 'svreinterpret_b' to cast from svcount_t to svbool_t.
Add builtin: 'svreinterpret_c'  to cast from svbool_t  to svcount_t.

Patch by: Hassnaa Hamdi <hassnaa.hamdi@arm.com>

Let the AtomicExpand pass do more of the job of expanding
AtomicRMWInst:s in order to simplify the handling in the backend.

The only cases that the backend needs to handle itself are those of
subword size (8/16 bits) and those directly corresponding to a target
instruction.

This code should only be run for intrinsics known to LLVM (otherwise
it will crash), not for everything that starts with "llvm.".

Reverts llvm/llvm-project#74837

Some build bot are failing because of missing constexpr.

https://lab.llvm.org/buildbot/#/builders/138/builds/56468/steps/7/logs/stdio

Fix #74258

The returned attribute can be used when it is possible to
"losslessly bitcast" between the argument and return type,
including between two vector types.

computeKnownBits() would crash in this case, isKnownNonZero()
would potentially produce a miscompile.

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

This patch fixes:

  clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:376:22: error:
  comparison of integers of different signs: 'unsigned int' and
  'TokenInfo::(unnamed enum at
  clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:356:7)'
  [-Werror,-Wsign-compare]

  clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:385:23: error:
  comparison of integers of different signs: 'unsigned int' and
  'TokenInfo::(unnamed enum at
  clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:356:7)'
  [-Werror,-Wsign-compare]

etc

With opaque pointers, the address spaces will only be the same if
the types are the same, in which case this would have been handled
at the start of the method already.

On platforms where char is signed, the ">> 4" shift will produce
incorrect results. We were already working on unsigned char for
most characters, but not for the first one.

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

…vset

According to the PR#257[1]

[1]ARM-software/acle#257

Co-authored by: Matthew Devereau <matthew.devereau@arm.com>

Cortex-M52 is an Armv8.1 AArch32 CPU.

Technical specifications available at:
  https://developer.arm.com/processors/cortex-m52

The intention is to merge some of the concat folds of vector constant data to address some of the remaining regressions in #73509

Instead of checking whether the GEP as a whole is constant, only
check whether it has constant incides. This matches what we do in
other places in this code.

This has little practical impact, because it is mostly already
handled through other cases anyway. We see a difference for
non-inbounds equality comparisons.

It was previously defined in the block where we defined back-deployment
features.

When assigning to a whole allocatable, lowering is dealing with the
implicit conversion to preserve the RHS lower bounds. In case of
character KIND mismatch, the code was setting the new RHS length to the
one from the LHS, which is wrong for two reasons:
- no padding/truncation was actually done in the conversion
- the RHS length should anyway not be touched since the one from the
allocatable LHS may change to become the one of the RHS.

Update the code to preserve the RHS type length when materializing the
implicit character KIND conversion.

As brought up in a previous review, instead of checking a token's
spelling in text everywhere, we added a 'special token kind'.
This adds the only other use of a special kind to use the checking
function instead.

I think it can work there but we need to correct the CHECK lines.

```
command-image-lookup-color.test:34:11: error: CHECK7: expected string not found in input
          ^
```
https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/10880/testReport/

I don't have a way to see the full output.

On Linux `main.c` shows up in the symbol search but this is not the
case on Windows according to:
https://lab.llvm.org/buildbot/#/builders/219/builds/7422/steps/6/logs/stdio

It's possible we could make this test work there once function
search highlighting is implemented.

We can assume the correct symbol is found, so putting the line
number here is just going to confuse anyone extending these tests.

It's surprisingly tricky to trigger this as it's only used by abs/neg
which expand into and/xor in the integer domain.