Fixes: #77411
When substituting deduced type, noexcept expr in function decl should be instantiated and evaluated.
ThisScrope should be switched to method context

Fixes: b8dface2

ThinLTO asan build may place `asan_globals` before the associated `.bss.xxx` section.
`rel->getOutputSection()` is nullptr because `rel->parent` hasn't been
set, leading to a crash. Simplify return `s->name` in this case.

It's been more than 3 years since -pgo-instr-old-cfg-hashing was
introduced by:

  commit 120e66b3
  Author: Hiroshi Yamauchi <yamauchi@google.com>
  Date:   Tue Jul 28 10:09:49 2020 -0700

I don't think anyone really cares about the ability to use the old CFG
hashing at this point.

Clang always silently ignores garbage target versions and this makes
debug harder. So clang will report when target versions are invalid.

illumos has an older version of the Solaris linker that does not
support the GNU version script compat nor version scripts and does
not support -Bsymbolic-functions. Treat illumos linker separately.

The libclang/CMakeLists part lifted from NetBSD's pkgsrc.

Build tested on Solaris 11.4 and OpenIndiana 2023.10.

/usr/bin/ld --version

ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.3260

ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1790 (illumos)

Complement #72610 (non-SHF_ALLOC sections). GCC-generated
.gcc_exception_table has the SHF_ALLOC flag and may contain
R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128 relocations.

This PR adds promised interface declarations for
`ConvertToLLVMPatternInterface` in all the dialects that support the
`ConvertToLLVM` dialect extension.

Promised interfaces allow a dialect to declare that it will have an
implementation of a particular interface, crashing the program if one
isn't provided when the interface is used.

This is needed to properly support Zve32x.

Targets affected:

- NVPTX and BPF: set to 64 bits.
- ARC, Lanai, and MSP430: set to 0 (they don't implement atomics).

Those which didn't yet add AtomicExpandPass to their pass pipeline now
do so.

This will result in larger atomic operations getting expanded to
`__atomic_*` libcalls via AtomicExpandPass. On all these targets, this
now matches what Clang already does in the frontend.

The only targets which do not configure AtomicExpandPass now are:
- DirectX and SPIRV: they aren't normal backends.
- AVR: a single-cpu architecture with no privileged/user divide, which
could implement all atomics by disabling/enabling interrupts, regardless
of size/alignment. Will be addressed by future work.

ANDN/ORN/XNOR are like other ALU instructions. It should be able to be
predicated by the cpu that supports short-forward-branch.

1. Improve the 'errno' modeling.
2. Improve constraints of the arguments.

Msan does not unwind stack in malloc without origins, but we still need
trace
for fatal errors.

Push #77391 into the main.

The fpext conversion cost for 16 elements should be 4 from Znver4.

Support fast math flag in the conversion of `complex.mulf` op to
standard dialect.

See:
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

This is still broken after #77350. Disable the warning for now, and fix
properly once the buildbot it back to green.

Link: https://github.com/llvm/llvm-project/issues/77395

https://reviews.llvm.org/D44780 implemented rudimentary support for
OVERLAY. The start address and `AT(ldaddr)` in `OVERLAY [start] :
[NOCROSSREFS] [AT ( ldaddr )]` are not optional.

In addition, there are two issues:

* When the start address is `.`, subsequent sections don't share the
  address of the first overlay section.
* When the first overlay section is empty and discardable, `p_paddr` is
  incorrectly zero. This is because a discarded section has a zero
  address, causing `prev->getLMA() + prev->size` where `prev` refers to
  the first section to evaluate to zero.

This patch supports optional start address and LMA and fix the issues.
Close #77265

Pull Request: https://github.com/llvm/llvm-project/pull/77272

Fixes the following from GCC:

    llvm-project/libc/src/string/memory_utils/op_x86.h:236:24: error:
conversion from ‘long unsigned int’ to ‘uint32_t’ {aka ‘unsigned int’}
may
    change value [-Werror=conversion]
      236 |   return (xored >> 32) | (xored & 0xFFFFFFFF);
          |          ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

Link:
https://lab.llvm.org/buildbot/#/builders/250/builds/16236/steps/8/logs/stdio
Link: https://github.com/llvm/llvm-project/pull/74506

Bitwise clear and exclusive or
Add pattern for:
    xor x, (and y, not(z)) -> bcax x, y, z

This reverts commit c68a9d25.

sifive-p450 supports a very restricted version of the short forward
branch optimization from the sifive-7-series.

For sifive-p450, a branch over a single c.mv can be macrofused as a
conditional move operation. Due to encoding restrictions on c.mv, we
can't conditionally move from X0. That would require c.li instead.

The changes to tablegen made by
https://github.com/llvm/llvm-project/pull/76825 result in
`StmtClass::lastStmtConstant` changing from `StmtClass::WhileStmtClass`
to `StmtClass::GCCAsmStmtClass`. Since `CFG::BuildOptions::alwaysAdd` is
never called with a `WhileStmt`, this has flown under the radar until
now.

Once such test in which an out-of-bounds access occurs is
`test/Sema/inline-asm-validate.c`, among many others.

`nvvm_fabs_f`
`nvvm_fabs_ftz_f`

Unfortunately, llvm fabs is not equivalent to these intrinsics since
llvm fabs is defined to only set the sign bit to zero while these can
also flush subnormal inputs and modify NaNs.

`nvvm_round_d`
`nvvm_round_f`
`nvvm_round_ftz_f`

llvm.nvvm.round uses RNI, while llvm.round codegens to RZI. LLVM defines
llvm.round to use the same rounding as libm
`round[f]()`, which is not necessary the same as how we define
llvm.nvvm.round.

`nvvm_sqrt_rn_f`
`nvvm_sqrt_rn_ftz_f`

sqrt may be lowered to a less precise version of sqrt, such as
sqrt.approx in NVPTX depending on factors such as the value of
-nvptx-prec-sqrtf32. These intrinsics should always become the
corresponding NVPTX instructions.

`nvvm_add_rn_d`
`nvvm_add_rn_f`
`nvvm_add_rn_ftz_f`
`nvvm_mul_rn_d`
`nvvm_mul_rn_f`
`nvvm_mul_rn_ftz_f`

These nvvm intrinsics have an explicitly specified rounding mode (.rn).
They should always be lowered to a PTX instruction with the same
explicit rounding mode. Converting to fmul and fadd instructions result
in the PTX instructions without rounding modes specified. This can cause
issue because:

> An add [or mul] instruction with no rounding modifier defaults to
round-to-nearest-even and may be optimized aggressively by the code
optimizer. In particular, mul/add sequences with no rounding modifiers
may be optimized to use fused-multiply-add instructions on the target
device.

`nvvm_div_rn_f`
`nvvm_div_rn_ftz_f`
`nvvm_rcp_rn_f`
`nvvm_rcp_rn_ftz_f`

fdiv may be lowered to a less precise version of div, such as div.full
in NVPTX depending on factors such as the value of -nvptx-prec-divf32.
These intrinsics should always become the corresponding NVPTX
instructions.

This extension has been superseded by SPV_KHR_cooperative_matrix which
is supported across major vendors GPU like Nvidia, AMD, and Intel.

Given that the KHR version has been supported for nearly half a year,
drop the NV-specific extension to reduce the maintenance burden and code
duplication.

Summary:
The offloading entries right now are assumed to be baked into the binary
itself, and thus always valid whenever the library is executing. This
means that we don't need to copy them to additional storage and can
instead simply pass around references to it.

This is not likely to change in the expected operation of the OpenMP
library. Additionally, the indirection for the offload entry struct is
simply two pointers, so moving it by value is trivial.

This addresses cases (currently failing) where we throw a null
pointer-to-object and fixes #64953.

We are trying to satisfy the following bullet from the C++ ABI 15.3:

* the handler is of type cv1 T* cv2 and E is a pointer type that can be
converted to the type of the handler by either or both of:

  - a standard pointer conversion (4.10 [conv.ptr]) not involving
    conversions to private or protected or ambiguous classes.

  - a qualification conversion.

The existing implementation assesses the ambiguity of bases by computing
the offsets to them; ambiguous cases are then when the same base appears
at different offsets. The computation of offset includes indirecting
through the vtables to find the offsets to virtual bases.

When the thrown pointer points to a real object, this is quite efficient
since, if the base is found, and it is not ambiguous and on a public
path, the offset is needed to return the adjusted pointer (and the
indirections are not particularly expensive to compute).

However, when we throw a null pointer-to-object, this scheme is no
longer applicable (and the code currently bypasses the relevant
computations, leading to the incorrect catches reported in the issue).

-----

The solution proposed here takes a composite approach:

1. When the pointer-to-object points to a real instance (well, at least,
it is determined to be non-null), we use the existing scheme.

2. When the pointer-to-object is null:

  * We note that there is no real object.
  * When we are processing non-virtual bases, we continue to compute the
    offsets, but for a notional dummy object based at 0. This is OK, since
    we never need to access the object content for non-virtual bases.
  * When we are processing a path with one or more virtual bases, we
    remember a cookie corresponding to the inner-most virtual base found so
    far (and set the notional offset to 0). Offsets to inner non-virtual
    bases are then computed as normal.

A base is then ambiguous iff:
* There is a recorded virtual base cookie and that is different from the
  current one or,
* The non-virtual base offsets differ.

When a handler for a pointer succeeds in catching a base pointer for a
thrown null pointer-to-object, we still return a nullptr (so the
adjustment to the pointer is not required and need not be computed).

Since we noted that there was no object when starting the search for
ambiguous bases, we know that we can skip the pointer adjustment.

This was originally uploaded as https://reviews.llvm.org/D158769.
Fixes #64953

If a category has no options associated with it, the `--help-hidden`
command still shows that category with the annotation "This option
category has no options", and this is how it was implemented from the
beginning when the categories were introduced, see commit 0537a988. A
feature to hide unrelated options was added later, in
https://reviews.llvm.org/D7100. Now, if a tool needs to hide unrelated
options that are associated with categories, leaving some of them empty,
those categories will still be visible on the `--help-hidden` output,
even if they have no use for the tool; see the changes in
`llvm/test/tools/llvm-debuginfo-analyzer/cmdline.test` for an example.

The patch ensures that only categories with options are shown on both
main and hidden help output.

Disallow using the form with a separate argument,
"--thinlto-cache-dir dir", allow only the one with equals,
"--thintlo-cache-dir=dir". This is the only form that actually was
tested when this was added in
f794808b, and matches the ELF side,
where only the form with an equals is supported (and this was also the
case at the time when this option was added to the MinGW linker).

Similar to #77345, the buildbots are observing similar warnings for the
sse2
implementation.

llvm-project/libc/src/__support/HashTable/sse2/bitmask_impl.inc:36:13:
    error: suggest braces around initialization of subobject
    [-Werror,-Wmissing-braces]
    return {bitmask};
            ^~~~~~~
            {      }
llvm-project/libc/src/__support/HashTable/sse2/bitmask_impl.inc:45:13:
    error: suggest braces around initialization of subobject
    [-Werror,-Wmissing-braces]
    return {static_cast<uint16_t>(~mask_available().word)};
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            {                                            }

Link:
https://lab.llvm.org/buildbot/#/builders/163/builds/49350/steps/8/logs/stdio
Link: https://github.com/llvm/llvm-project/pull/74506

This is a follow-up to (#71613) and (#71961).

AddName gives no feedback other than if it succeeded whereas
AddNameWithErrorHandling gives you back an SBError object. I would like
to mark AddName as deprecated and direct folks to use
AddNameWithErorrHandling instead.

---------

Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>