With one raw memprof file I have, NumPCs averages about 41.  Given the
default number of inline elements being 8 for SmallVector<uint64_t>,
we should reserve the storage in advance.

The MinBW was being calculated using the significant bits of the upper
and lower bounds. The upper bound is 1 past the last value in the range
so I don't think it should be included. Instead use ConstantRange::getMinSignedBits.

I'm still not sure if the +1 is needed after the getMinSignedBits call.

Just went a quick replacement of `N{U,S}WAdd` with the `Like` variant
that old matches `or disjoint`

Closes #86082

`or disjoint` implies `add nuw nsw`: https://alive2.llvm.org/ce/z/VABhDA

[Flang] Support for NULL() and procedure in structure constructor for procedure pointer component. (#85991)

This PR fixes a subset of procedure pointer component initialization in
structure constructor.
It covers
  1. NULL()
  2. procedure
  
 For example:
 ```
   MODULE M
    TYPE :: DT
      !PROCEDURE(Fun), POINTER, NOPASS :: pp1
      PROCEDURE(Fun), POINTER :: pp1
    END TYPE

    CONTAINS

    INTEGER FUNCTION Fun(Arg)
     class(dt) :: arg
    END FUNCTION

  END MODULE

  PROGRAM MAIN
  USE M
  IMPLICIT NONE
  TYPE (DT), PARAMETER :: v1 = DT(NULL())
  TYPE (DT) :: v2
  v2 = DT(fun)
  END
  ```
  
Passing a procedure pointer itself or reference to a function that
returns a procedure pointer is TODO.

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



Changes:
- Adapted MemRegion::getDescriptiveName
- Added unittest to check name for a given clang::ento::ElementRegion
- Some format changes due to clang-format

---------

Co-authored-by: Andreas Steinhausen <andreas.steinhausen@concenrio.io>
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>

Inside the ExprEngine when we process the initializers, we create a
PostInitializer program-point, which will refer to the field being
initialized, see `FieldLoc` inside `ExprEngine::ProcessInitializer`.

When a constructor (of which we evaluate the initializer-list) is
analyzed in top-level context, then the `this` pointer will be
represented by a `SymbolicRegion`, (as it should be).

This means that we will form a `FieldRegion{SymbolicRegion{.}}` as the
initialized region.

```c++
class Bear {
public:
  void brum() const;
};
class Door {
public:
  // PostInitializer would refer to "FieldRegion{SymRegion{this}}"
  // whereas in the store and everywhere else it would be:
  // "FieldRegion{ELementRegion{SymRegion{Ty*, this}, 0, Ty}".
  Door() : ptr(nullptr) {
    ptr->brum(); // Bug
  }
private:
  Bear* ptr;
};
```

We (as CSA folks) decided to avoid the creation of FieldRegions directly
of symbolic regions in the past:

https://github.com/llvm/llvm-project/commit/f8643a9b31c4029942f67d4534c9139b45173504

---

In this patch, I propose to also canonicalize it as in the mentioned
patch, into this: `FieldRegion{ElementRegion{SymbolicRegion{Ty*, .}, 0,
Ty}`

This would mean that FieldRegions will/should never simply wrap a
SymbolicRegion directly, but rather an ElementRegion that is sitting in
between.

This patch should have practically no observable effects, as the store
(due to the mentioned patch) was made resilient to this issue, but we
use `PostInitializer::getLocationValue()` for an alternative reporting,
where we faced this issue.

Note that in really rare cases it suppresses now dereference bugs, as
demonstrated in the test. It is because in the past we failed to follow
the region of the PostInitializer inside the StoreSiteFinder visitor -
because it was using this code:
```c++
// If this is a post initializer expression, initializing the region, we
// should track the initializer expression.
if (std::optional<PostInitializer> PIP =
        Pred->getLocationAs<PostInitializer>()) {
  const MemRegion *FieldReg = (const MemRegion *)PIP->getLocationValue();
  if (FieldReg == R) {
    StoreSite = Pred;
    InitE = PIP->getInitializer()->getInit();
  }
}
```
Notice that the equality check didn't pass for the regions I'm
canonicalizing in this patch.

Given the nature of this change, we would rather upstream this patch.

CPP-4954

Reverts llvm/llvm-project#80855

[libc++] Remove macros for keeping std::allocator members and void specialization after C++20 (#85806)

Fixes #75975.

Remove `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` for the LLVM 19
release, it was previously marked as deprecated in LLVM 18.

I believe that
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` was only
used by Google in conjunction with
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`.

Removing both macros together should not cause any issues in practice,
even though we did not announce the removal of
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` before.

Noticed in debug logs - most calls to visitVECTOR_SHUFFLE resulted into wasteful UNDEF node creations, despite almost never being used.

SYS_rename may be unavailable on architectures such as aarch64 and
riscv.
rename can be implemented in terms of SYS_rename, SYS_renameat, or
SYS_renameat2. I don't have a full picture of the history here, but it
seems
that SYS_renameat might also be unavailable on some platforms.

`man 2 rename` mentions that SYS_renameat2 was added in Linux 3.15. We
don't
need to support such ancient kernel versions prior.

Link: #84980
Link: #85068

Fixes #83075, fixes #83076.

This will replace `__builtin_is_constant_evaluated` in math_extras.h.

We were passing the min and max values of the range to the ConstantRange
constructor, but the constructor expects the upper bound to 1 more than
the max value so we need to add 1.

We also need to use getNonEmpty so that passing 0, 0 to the constructor
creates a full range rather than an empty range. And passing smin,
smax+1 doesn't cause an assertion.

I believe this fixes at least some of the reason #79158 was reverted.

Some header guards conflicted with clang. Fix a few others to follow the
convention in the rest of the headers in flang.

Previously we used BuildPairF64 and SplitF64 only if Zfa was supported
since they will select register file moves that are only available with
Zfa.

We recently changed the handling of BuildPairF64/SplitF64 for Zdinx to
not go through memory so we should use that for bitcast.

That leaves the D without Zfa case that does need to go through memory.
Previously we let type legalization expand to loads and stores using a
new stack temporary created for each bitcast. After this patch we will
create the loads ands stores in the custom inserter and share the same
stack slot for all. This also allows DAGCombiner to optimize when
bitcast is mixed with BuildPairF64/SplitF64.

The Doxygen comments for the `details` field of a progress report
currently does not specify that this field will act as the initial set
of details for a progress report that gets updated with
`Progress::Increment()`. This commit clarifies this.

Investigate the lowering of MemRef Load/Store ops and implement
additional folding of created ops

Aims to improve readability of generated lowered SPIR-V code.

Part of work llvm#70704

The range for these operations is being constructed without the
maximum value for the range due to an incorrect usage of the
ConstantRange constructor.

This causes Float2Int to think the range for 'uitofp i1' only
contains 0 instead of 0 and 1.

This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
functional change of storing the support file from the line table (yet).

Link: #84980
Link: #85068

Dwarf 5 allows separating filenames from .debug_line into a separate
.debug_line_str section. The strings are referenced relative to the
start of the .debug_line_str section. Previously, on COFF, the
relocation information instead caused offsets to be relocated to the
base address of the COFF-File. This lead  to wrong offsets in linked
COFF (PE) files which caused the debugger to be unable to find the
correct source files.

This patch fixes this problem by making the offsets relative to the
start of the .debug_line_str section instead. There should be no
changes for ELF-Files as everything seems to be working there.

A test is also added to ensure that the correct relocation entries are
emitted.

This reapplies 272d1b44 (from #85756),
which was reverted in
40793703.

In the previous attempt, empty CMAKE_INSTALL_PREFIX was handled by
quoting them, in d209d134. That made the
calls to cmake_path(ABSOLUTE_PATH) succeed, but the output paths of that
weren't actually absolute, which was required by file(RELATIVE_PATH).

Avoid this issue by constructing a non-empty base directory variable
to use for calculating the relative path.

Adds stdio.h's rename() function as defined in n3096. Fixes  #84980.

I believe we can use XLen alignment as long as eliminateFrameIndex
limits the maximum folded offset to 2043. This way when we split
the load/store into two 2 instructions we'll be able to add 4
without overflowing simm12.

Allow targets to rely on TargetLowering::isGuaranteedNotToBeUndefOrPoisonForTargetNode to test nodes for canCreateUndefOrPoisonForTargetNode + all arguments are isGuaranteedNotToBeUndefOrPoison.

Targets can still perform this themselves for specific special case nodes (e.g. target shuffles).

Matches the fallback in SelectionDAG::isGuaranteedNotToBeUndefOrPoison

if cost threshold is very low.

Document expectations for contributions to InstCombine, especially
regarding test coverage and alive2 proofs.

Check for all frame instructions in finalize isel, not just for the
frame setup opcode. This was proven necessary, see #78001 
for discussion.

NFC.
Fix CHECK lines that seem to have a copy paste error.
Move the test that was formerly in gfx12_dasm_vinterp.txt (see #85949).

NFC.
gfx11_asm_vinterp.s already contained GFX12 run lines. Rename the
assembler and disassembler tests to be sorted based on real16 or fake16
instead of gfxip. Note, both GFX11 and GFX12 currently only have fake16
(fake16 in encoding, but not by name) upstream, so that is why the test
files have a -fake16 suffix.

One test input is changed, and that is the disassembler test for
unsupported bits in the instruction. It is now an input that is valid on
both GFX11 and GFX12. This was necessary because the size of the opcode
field changed.

This adds a new API built with the `ValueBoundsConstraintSet` to compute
the bounds of possibly scalable quantities. It uses knowledge of the
range of vscale (which is defined by the target architecture), to solve
for the bound as either a constant or an expression in terms of vscale.

The result is an `AffineMap` that will always take at most one
parameter, vscale, and returns a single result, which is the bound of
`value`.

The API is defined as follows:

```c++
FailureOr<ConstantOrScalableBound>
vector::ScalableValueBoundsConstraintSet::computeScalableBound(
  Value value, std::optional<int64_t> dim,
  unsigned vscaleMin, unsigned vscaleMax,
  presburger::BoundType boundType, 
  bool closedUB = true,
  StopConditionFn stopCondition = nullptr);
```

Note: `ConstantOrScalableBound` is a thin wrapper over the `AffineMap`
with a utility for converting the bound to a single quantity (i.e. a
size and scalable flag).

We believe this API could prove useful downstream in IREE (which uses a
similar analysis to hoist allocas, which currently fails for scalable
vectors).

This adds a libc++ to modules.json as is currently used by libc++. When
libc++.so is not found the function will search for libc++.a as
fallback.

macosx and darwin in triples are equivalent.

rdar://124246653