This commit adds a `ValueBoundsOpInterface` implementation for
`arith.select`. The implementation is almost identical to `scf.if`
(#85895), but there is one special case: if the condition is a shaped
value, the selection is applied element-wise and the result shape can be
inferred from either operand.

This commit simplifies the implementation of the
`ValueBoundsOpInterface` for `scf.for` based on the newly added
`ValueBoundsConstraintSet::compare` API and adds additional
documentation.

Previously, the interface implementation created a new constraint set
just to check if the yielded value and iter_arg are equal. This was
inefficient because constraints were added multiple times (to two
different constraint sets) for ops that are inside the loop.

Note: This is a re-upload of #86239.

[CWG466](https://cplusplus.github.io/CWG/issues/466.html) "cv-qualifiers
on pseudo-destructor type".
Richard claimed that we don't implement this DR because of one
ill-formed example being accepted: `a->CI::~VI();`. This example is
testing the behavior of calling a pseudo-destructor via a qualified
name, where components of qualified name denote the same `int` type, but
with different cv-qualifications.

Initially, the following wording from [expr.pseudo] quoted in CWG466 was
left intact:
> Furthermore, the two type-names in a pseudo-destructor-name of the
form
>
>    `:: (opt) nested-name-specifier (opt) type-name ::~ type-name`
>
>shall designate the same scalar type.

According to this wording, the example is indeed ill-formed.

[P1131R2](https://wg21.link/p1131r2) merged wording for
pseudo-destructors into regular destructor wording. Among other things,
[expr.pseudo] was removed, and [expr.prim.id.qual]/2 was changed to
read:

> Where `type-name ::~ type-name` is used, the two type-names shall
refer to the same type (ignoring cv-qualifications);

I believe P1131R2 made the example well-formed.

However, this wording didn't survive
[P1787R6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html)
"Declarations and where to find them". In that paper I don't see the
intent to make the example ill-formed again, so I assume it confirmed
status-quo via other wording. My _guess_ the new wording is
http://eel.is/c++draft/basic.lookup#qual.general-4.6:
> If a qualified name Q follows a ~: 
> - <...>
> - The [type-name](http://eel.is/c++draft/dcl.type.simple#nt:type-name)
that is or contains Q shall refer to its (original) lookup context
(ignoring cv-qualification) under the interpretation established by at
least one (successful) lookup
performed[.](http://eel.is/c++draft/basic.lookup#qual.general-4.6.sentence-1)

[CWG392](https://cplusplus.github.io/CWG/issues/392.html) "Use of full
expression lvalue before temporary destruction". We're testing that
`operator bool()` is called before destructor of `C`.

I'm also marking CWG388 as requiring libc++abi test instead of codegen
test, as we need to test matching between exception object and exception
handlers.

This is a follow-up to #81506. Since `__is_layout_compatible()` is a C++
intrinsic
(https://github.com/llvm/llvm-project/blob/ff1e72d68d1224271801ff5192a8c14fbd3be83b/clang/include/clang/Basic/TokenKinds.def#L523),
I don't think we should define how it interacts with VLA extension
unless we have a compelling reason to.

Since #81506 was merged after 18 cut-off, we don't have to follow any
kind of deprecation process.

This commit adds support for `scf.if` to `ValueBoundsConstraintSet`.

Example:
```
%0 = scf.if ... -> index {
  scf.yield %a : index
} else {
  scf.yield %b : index
}
```

The following constraints hold for %0:
* %0 >= min(%a, %b)
* %0 <= max(%a, %b)

Such constraints cannot be added to the constraint set; min/max is not
supported by `IntegerRelation`. However, if we know which one of %a and
%b is larger, we can add constraints for %0. E.g., if %a <= %b:
* %0 >= %a
* %0 <= %b

This commit required a few minor changes to the
`ValueBoundsConstraintSet` infrastructure, so that values can be
compared while we are still in the process of traversing the IR/adding
constraints.

Note: This is a re-upload of #85895, which was reverted. The bug that
caused the failure was fixed in #87859.

The C++ standard does not specify an evaluation order for addition/...
operands. E.g., in `a() + b()`, the compiler is free to evaluate `a` or
`b` first.

This lead to different `mlir-opt` outputs in #85895. (FileCheck passed
when compiled with LLVM but failed when compiled with gcc.)

Lift the requirement that rbegin/rend must be member functions. Also
allow the rbegin/rend to be found through Argument Dependent Lookup
(ADL) and add `adl_rbegin`/`adl_rend` to STLExtras.

Emitting trivial getters that amount to `(*this)->getOperand(1)`
out-of-line or `getProperties().foo` is a pretty significant performance
hit on these basic MLIR APIs for manipulating ops (3-4x). Emit them
inline (without adding additional dependencies to header files).

Completely skip include directives that form the filename using macros.

fixes #87303

Emit the recorded number of blocks, not the number of basic block
hashes. There might be differences in corner cases (openssl
BN_BLINDING_convert_ex function).

Test Plan:
Updated openssl.test in https://github.com/rafaelauler/bolt-tests/pull/31

Reviewers: rafaelauler, ayermolo, maksfb, dcci

Reviewed By: ayermolo

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

BAT writeMaps encoded the assumption that functions are only split into
two fragments (hot and cold). However, BOLT supports splitting into
arbitrary number of fragments. Relax that assumption and look up primary
(hot) fragment explicitly.

Depends on: https://github.com/llvm/llvm-project/pull/86219

Test Plan: Updated bolt/test/X86/yaml-secondary-entry-discriminator.s

Reviewers: ayermolo, rafaelauler, maksfb, dcci

Reviewed By: maksfb, dcci

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

This has been updated in the isa-manual
https://github.com/riscv/riscv-isa-manual/pull/1311

llvm-project/flang/lib/Lower/Bridge.cpp:3775:14:
error: variable 'nbDeviceResidentObject' set but not used [-Werror,-Wunused-but-set-variable]
    unsigned nbDeviceResidentObject = 0;
             ^
1 error generated.

Provide a mechanism to resolve call target information for calls from non-BAT
functions to BAT functions (`YAMLProfileWriter::convert`). Make it generic for
future use in BAT-to-BAT calls.

Test Plan: Updated bolt/test/X86/bolt-address-translation-yaml.test

Reviewers: ayermolo, maksfb, rafaelauler, dcci

Reviewed By: maksfb

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

Context: https://github.com/llvm/llvm-project/pull/87017

- Add proxy header `libc/hdr/math_macros.h` that will:
  - include `<math.h>` in overlay mode,
- include `"include/llvm-libc-macros/math-macros.h"` in full build mode.
- Its corresponding CMake target `libc.hdr.math_macros` will only depend
on `libc.include.math` and `libc.include.llvm-libc-macros.math_macros`
in full build mode.
- Replace all `#include "include/llvm-libc-macros/math-macros.h"` with
`#include "hdr/math_macros.h"`.
- Add dependency to `libc.hdr.math_macros` CMake target when using
`add_fp_unittest`.
- Update the remaining dependency.
- Update bazel overlay: add `libc:hdr_math_macros` target, and replacing
all dependency on `libc:llvm_libc_macros_math_macros` with
`libc:hdr_math_macros`.

I will add `toupper` implementation into it in the next PR.

The lowering of n-D vector.extract/insert ops to LLVM is not supported
but if one of these accidentally reaches the vector-to-llvm conversion
patterns, we end up with a kind of puzzling crash. This PR fixes that
crash and gracefully bails out in those cases.

When building flang out-of-tree with relative paths in LLVM_DIR,
CLANG_DIR and MLIR_DIR, we need to compute the absolute paths
based on the CMake build directory (i.e. where the cmake is invoked
from).

This script+config should help us generate more consistent documentation wrt.
what we currently support or not.

As an example usage:

    $ ./libc/utils/docgen/docgen.py fenv.h

Will spit out an RST formatted table that can be copy+pasted into our docs.

The config is not filled out entirely, but doing so and then updating our docs
would be great beginner bugs for new contributors.

Having python+json generate things like docs, or headers (as imagined in
https://github.com/nickdesaulniers/llvm-project/tree/hdr-gen2) is perhaps
easier to work with than tablegen, and doesn't introduce a dependency on a host
tool that needs to be compiled from llvm sources before building the rest of
the libc. This can probably be merged with whatever we end up doing to replace
libc-hdrgen.

Please use

https://llvm.org/docs/CodingStandards.html#python-version-and-source-code-formatting
for keeping this file formatted.

fatal error for now

Appeases build bots while being investigated.

Take care of a TODO. This
check makes sure that the fexcept_t
value fits in an int value.

TODO introduced in:
https://github.com/llvm/llvm-project/commit/9550f8ba9a3a697f28a7920c8aeb5cba1e8003a6

The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the libfuzzer tests. This allows a clang built on a machine with a
new linker to run compiler-rt tests on a machine with an old linker.

rdar://125932376

Building the Apple way turns off plugin support, meaning we don't need
to export unloadable symbols from all executables. While deadstripping
effects aren't expected to change, enabling this across all tools
prevents the creation of export tries. This saves us ~3.5 MB in just the
universal build of `clang`.

These are new in clang-19+, gcc-14+.

Added unit tests for all of the linux report error functions.

* Capture reexported libraries, allowable clients, rpaths, shared cache
eligibility.
* Add support for select Xarch options.
* Add diagnostics related to capturing these options.
* Add support for verifying these attributes against what is encoded in
the dylib.

Closes #87564

In section 3.4.2, some example of illegal data transfer using expression
are given. One of it is when multiple device objects are part of an
expression in the rhs. Current implementation allow a single device
object in such case. This patch adds a similar restriction.

Until we can reliably check the legality and improve our selection of these,
don't form them at all.

These tests consist of patterns like (sh3add Z, (add X, (slli Y, 6)))
that can be reassociated to form (sh3add (sh3add Y, Z), X).

Previously we only checked for C.

sed was being used to use the same test functions with eq/ne branch
condition.

This commit duplicates the test functions so that we have a version
with each condition. This allows us to remove 2 RUN lines.

I plan to add a Zca testing to this file which now requires 1 new
RUN line instead of 2.

Followup to issues addressed here: #87397

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

The aggregate deduction guides are handled in a separate code path. We
don't generate dedicated aggregate deduction guides for alias templates
(we just reuse the ones from the underlying template decl by accident).
The patch fixes this incorrect issue.

Note: there is a small refactoring change in this PR, where we move the
cache logic from `Sema::DeduceTemplateSpecializationFromInitializer` to
`Sema::DeclareImplicitDeductionGuideFromInitList`

While attempting to build some Rust code, I was getting linker errors
due to missing functions that are implemented in `compiler-rt`. Turns
out that when `compiler-rt` is built for Arm64EC, all its function names
are mangled with the leading `#`.

This change removes the hard-coded list of library-implemented
intrinsics to mangle for Arm64EC, and instead assumes that they all must
be mangled.

Implements: https://wg21.link/P2872R3