The function DWARFASTParserClang::ParsePointerToMemberType attempts to make
two pointers and then immediately tries to dereference them, without
verifying that the pointesr were successfully created. Sometimes the pointer
creation fails, and the dereference then causes a segfault. This add a check
that the pointers are non-null before attempting to dereference them.

Re-land D146987.

This reverts commit 4f1954ed which
reverts D146987.

This avoids the use-after-free introduced by D147794 and fixed
in 437dfa5b.

Added ShuffleCostEstimator class and the first adjustExtracts member,
which is just a copy of previous AdjustExtractCost lambda.

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

Fixed https://github.com/llvm/llvm-project/issues/56022
c++20 support namespace like `namespace a::inline b {}`.
If an inline namespace is not the first, it can be concatened.

Reviewed By: PiotrZSL

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

[[https://wg21.link/p1787 | P1787]]: CWG1837 is resolved by restricting `this` to referring to the innermost enclosing class.
Wording: see changes to [expr.prim.this] and [expr.prim.lambda].

Reviewed By: #clang-language-wg, erichkeane

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

[[https://wg21.link/p1787 | P1787]]: CWG2007 is resolved by skipping unqualified lookup for operators that must be member functions.
Wording: For the operators =, [], or ->, the set of non-member candidates is empty; otherwise, it includes the result of the unqualified lookup for operator@... ([over.match.oper]/3)

Reviewed By: #clang-language-wg, shafik

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

[[https://wg21.link/p1787 | P1787]]: CWG2370 is resolved by performing a search in (only) the immediate scope of any friend, per the [[ http://wiki.edg.com/bin/view/Wg21sandiego2018/CoreWorkingGroup#Core_issue_2370_friend_declarati | CWG opinion from San Diego ]].
Wording: In a friend declaration declarator whose declarator-id is a qualified-id whose lookup context is a class or namespace S, lookup for an unqualified name that appears after the declarator-id performs a search in the scope associated with S. If that lookup finds nothing, it undergoes unqualified name lookup. ([basic.lookup.unqual]/6).

Clarification for P1787 description: when applied to the test in this patch, "immediate scope" refers to `N`, and "(only)" refers to the fact that `type` is not searched in parent scope of `N`. See example after the wording if additional clarification is needed. The most relevant line there is `friend void A::f(F);  // OK`.

Reviewed By: #clang-language-wg, shafik

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

Use likely have tagged pointer. I see no value making user to untag it.

Reviewed By: fmayer

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

Per https://reviews.llvm.org/D147970#4256889, swab.cpp is moved out of
the /linux subdirectory and cmake specifications are amended to reflect
that swab is not OS-specific.

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

The LMUL for data and index are not guaranteed the same so we need different LMULs appended to the sched classes for them.

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

This read is for a gpr pointer, and doesn't need to be LMUL aware.

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

There's no reason these strings need to be in the ConstString
StringPool, they're already string literals with static lifetime.

I plan on addressing other similar functions in follow up commits.

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

The acc.loop operation was constrained by the SingleBlockImplicitTerminator.
This patch relax this constraint to allow multiple block in the loop.

Reviewed By: razvanlupusoru

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

Instead of rejecting the CPU outright with no information, try
to diagnose that it doesn't match the triple.

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

This function was used to force +64bit or -64bit into the feature
string basd on -mcpu.

It's not entirely clear to me why this was needed.  This informationo
is redundant with the triple. RISCVTargetInfo::initFeatureMap
independently recomputes it from the triple for the feature map.

It is ultimately needed in the backend, but that should be handled
by RISCVSubtarget processing the CPU name.

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

Pass -flto-jobs to orbis-ld correctly.

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

In D147777 emitDbgAssign was fixed to discard assignments which touched any
bits outside the bounds of a variable. This patch changes emitDbgAssign to
discard assignments which touch bits only outside the variable bounds, and
creates a truncated fragment expression for stores partially overlapping the
variable. This is necessary because the alloca is interpreted as a store (of
undef), meaning without this patch emitDbgAssign would discard the inital
dbg.assign for a variable that is smaller than the alloca.

Reviewed By: jmorse

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

Some dbg.assigns using poison become un-poisoned in SROA. The reason this
happens at all is because dbg.assigns linked to memory intrinsics use poison to
indicate they can't describe the stored value, but the value becomes available
after some optimisations. This needs reworking eventually, but for now we need
to ensure that when it does occur we don't create invalid expressions.

D147312 prevented this occuring when the dbg.assign uses DIArgLists, but that
wasn't a complete fix. We also need to ensure we avoid un-poisoning when the
existing expression uses more than one location operand (DW_OP_arg, n).

Reviewed By: jmorse

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

We try to use X32 just for gnux32 triples

Some compilers require std::make_optional(std::move()) to force construction
of the std::optional return value. This should fix the build failure in
  https://lab.llvm.org/buildbot#builders/67/builds/10991

The __cpp_lib_format_ranges feature-test macro only depends on P2286R8
and P2585R0. Note since LWG3750 only affects these two C++23 papers
there is nothing to do for older language versions.

(The __cpp_lib_format feature-test macro depends on the incomplete
formatting for chrono. So this part can't be marked as complete yet.)

This completes
- P2286R8 Formatting ranges
- P2585R0 Improving default container formatting

This partly implements
- LWG3750 Too many papers bump __cpp_lib_format

Reviewed By: #libc, ldionne

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

This is based on the last open review comment in D144331 and is applied
to all occurrences.

Reviewed By: ldionne, #libc

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

D144994 adds modules to libc++. In order to test them some newer and
additional tools are required.

CMake 3.26
This is in combination with Clang 16 or newer makes it possible to
conveniently build modules with CMake. Unfortunately CMake 3.26 in our
setup has an issue with unused linker flags. This causes libunwind not
to compile at all. D145596 contains a quick-fix which is in the module
patch. The patch D142957 and followups will contain a proper fix.
Therefore install CMake 3.26 in a separate location, allowing to test
the module patch in the CI.

Ninja 1.11
Building modules requires dynamic rules, which requires this version.
This is a CMake 3.26 requirement to use modules. Note that without using
modules CMake still accepts older Ninja versions.

clang-scan-deps (in the tools package)
This tool is used by CMake to get the module dependencies. Note
strictly this currently will only be used for Clang 16 and Clang 17.
Clang 15 and Clang 14 are not needed. They are installed to keep
updating to Clang 18 and later easier.
(In the future we might not test modular build with all Clang versions,
however at the moment the feature is still in development in both Clang
and libc++ so it would be good to detect regressions.)

Reviewed By: #libc, ldionne

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

Reviewed By: #libc, Mordante

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

The last time this function was updated DIArgLists were not supported for
dbg.assigns. Without this patch it's possible to now dereference an invalid
(the end) iterator. This occurs when the Address component gets replaced and
there's a DIArgList for the Value component (the contained values are
irrelevant).

The added unittest crashes without the code change in this patch.

Reviewed By: jmorse

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

Allows pack propagation through non-elementwise generics as long as all
tiled dimensions have parallel iterator types and are only indexed with
affine dim expressions by any of the operands.

This enables unpack propagation cases where the result type is different
from the current unpack destination tensor and thus motivates a similar
helper as the for pack for creating a destination tensor based on
pack information.

Outer dim permutations are allowed to permute reduction dims, however
remains unsupported for non-affine dim indexing map results.
Additionally ops with gather semantics now explicitly prohibit propagation.

Pack/unpack propagation through reductions may not always be beneficial
so user control over propagation decisions is made available through
a control function similar to the one for fusion.

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

- As the address space cast may not be valid on a specific target,
  `addrspacecast` is not handled when an `alloca` is able to be replaced
  with the source of memcpy/memmove. This patch addresses that by
  querying a target hook on whether that address space cast is valid.
  For example, on most GPU targets, the cast from a global pointer to a
  generic pointer is valid.
- If that cast is allowedd (by querying `isValidAddrSpaceCast`), the
  replacement is enhanced to handle that `addrspacecast` as well.

Reviewed By: yaxunl

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

The error message that is displayed when the offset in the MemRefType of
the Op's result is unexpected was the wrong way around, mixing up
expected and actual offset.

Reviewed By: ftynse

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

This enables conversion of OpenMP Target op with region from FIR Dialect to LLVM IR Dialect.

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

Report an error when the `iterator_types` attribute is missing.

Reviewed By: nicolasvasilache

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

This patch adds Fortran lowering support for OMP Target directive along with tests.

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

In particular, move the printing of the top-level payload after each
transform under the "full output" debug flag, it is rarely useful and
excessively long. Also don't print the regions of the transform
operation being applied as each individual operation in the region is
likely going to be applied later by itself and therefore printed.

Reviewed By: nicolasvasilache

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

Added map clause support for the OMP Target directive with test.

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

As described in [0], this extends IRPGO to support //Temporal Profiling//.

When `-pgo-temporal-instrumentation` is used we add the `llvm.instrprof.timestamp()` intrinsic to the entry of functions which in turn gets lowered to a call to the compiler-rt function `INSTR_PROF_PROFILE_SET_TIMESTAMP()`. A new field in the `llvm_prf_cnts` section stores each function's timestamp. Then in `llvm-profdata merge` we convert these function timestamps into a //trace// and add it to the indexed profile.

Since these traces could significantly increase the profile size, we've added `-max-temporal-profile-trace-length` and `-temporal-profile-trace-reservoir-size` to limit the length of a trace and the number of traces in a profile, respectively.

In a future diff we plan to use these traces to construct an optimized function order to reduce the number of page faults during startup.

Special thanks to Julian Mestre for helping with reservoir sampling.

[0] https://discourse.llvm.org/t/rfc-t...

We have now seen two miscompiles because of widening widenable
conditions at incorrect IR points and thereby changing a branch's loop
invariant condition to a loop-varying one (see PR60234 and PR61963).

This patch adds asserts in common guard utilities that we use for
widening to proactively catch these bugs in future.
Note that these asserts will not fire if we were to sink a widenable
condition from out of a loop into a loop (that's also incorrect for the
same reason as above).

Tested this without the fix for PR60234 (guard widening miscompile) and
confirmed the assert fires.

WARNING: Sometimes, the assert can fire if we failed to hoist the
invariant condition out of the loop. This is a pass-ordering issue or a
limitation in LICM, which would need an investigation. See details in
review.

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