This is the equivalent of 340b48b2 applied to the non-experimental
std::pmr.

These "implementation detail" function templates were already
hidden and have no specializations in the dylib, so they seem like they can safely
use _LIBCPP_HIDE_FROM_ABI instead and have the abi tags applied as well.

Seems some of these got over looked (e.g. D129823) in various places, and they
won't be flagged by the new checks added in D129968, as they were
already hidden.

Reviewed by: ldionne

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

When -lxxx is specified, if there happens to have a directory or
file with name xxx, clang will not look up libxxx.a, but will
try to unbundle xxx instead.

Reviewed by: Saiyedul Islam, Artem Belevich

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

These headers are uncommonly used, and from extensions, but some basic
support is needed. Macros have been added where available.

Reviewed By: sivachandra

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

This is a workaround until perfect shuffle generation is improved.

This patch teaches `clang` to use the prefix `-bplugin_opt:` (instead of `-plugin-opt`) on AIX, when passing plugin options to the linker. This patch follows https://reviews.llvm.org/D134668.

We put the code that decides what plugin option prefix to use at the top of the function `tools::addLTOOptions`. The plugin option prefix, the mcpu prefix, and the opt level prefix are different on AIX. We thought about choosing the strings in a function that reads the linker name and the target triple, or we could push the logic into different derived `ToolChain` classes. But this logic would not be used anywhere else, so these alternatives looked too complicated for what they did. Therefore we are doing it the current way. That said, I am all ears for suggestions to improve this code!

Subsequent code uses the `PluginOptPrefix` variable consistently instead of the hardcoded `-plugin-opt`.

Reviewed By: MaskRay

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

Reviewed By: foad

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

This reverts commit 79ee0342 which
breaks the LLVM TSan bots.

When training large models, we encounter use-after-free bugs when
writing to the input tensors for various MLGO models. This patch fixes the
issue by marking the tensors as "persistent".

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

Breaks up a large function and allows for the use to early exits.

Allowing incorrect version scripts is not a helpful default. Flip that
to help users find their bugs at build time rather than at run time.

Reviewed By: MaskRay

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

Without this, unwinding through functions that does use PAC
would fail, if PAC actually was active.

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

This new opcode was initially documented as "pac_sign_return_address"
in https://github.com/MicrosoftDocs/cpp-docs/pull/4202, but was
soon afterwards renamed into "pac_sign_lr" in
https://github.com/MicrosoftDocs/cpp-docs/pull/4209, as the other
name was unwieldy, and there were no other external references to
that name anywhere.

Rename our external .seh assembler directive - it hasn't been merged
for very long yet, so there's probably no external use to account for.

Rename all other internal references to the opcode similarly.

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

86771d0b introduced some fialure for flang

https://buildkite.com/llvm-project/premerge-checks/builds/116406#0183ca8c-bc14-4314-9b1d-c764cf47e0aa

Update FIROps.td to fix the issues.

If an invalid architecture is set we currently return an empty string.
This will cause the offloading toolchain to continue to be built and
hit an assertion elsewhere due to the invalid architecture. This patch
fixes that so we now correctly exit.

Reviewed By: tra

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

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

Matches CMake build.
Otherwise currently everything is literally std::_LIBCPP_ABI_NAMESPACE::foo.

See https://reproducible-builds.org/docs/source-date-epoch/ . The environment
variable ``SOURCE_DATE_EPOCH`` been recognized by many compilers.

In GCC, if `SOURCE_DATE_EPOCH` is set, it specifies a UNIX timestamp to be used
in replacement of the current date and time in the `__DATE__` and `__TIME__`
macros. Note: GCC as of today does not update `__TIMESTAMP__` (the modification
time of the current source file) but
https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros expresses the
intention to update it.

This patches parses SOURCE_DATE_EPOCH and changes all the three macros.

In addition, in case gmtime/localtime returns null (e.g. on 64-bit Windows
gmtime returns null when the timestamp is larger than 32536850399
(3001-01-19T21:59:59Z)), use `??? ?? ????` as used by GCC.

Reviewed By: ychen

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

When zlib is disabled at build time, the diagnostic `LLVM was not compiled with
LLVM_ENABLE_ZLIB: cannot decompress` for --decompress-debug-sections may be
inaccurate: if zstd is enabled, we should still support zstd decompression.

It's not useful to test zlib and zstd. Just remove the diagnostic and add a new
one before `compression::decompress`.

This fixes compress-debug-sections-zstd.test

Reviewed By: mariusz-sikora-at-amd, jhenderson, phosek

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

This moves some includes missed in D133212.

Reviewed By: ldionne, #libc, philnik

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

[modules] Allow to validate system headers less often with `-fmodules-validate-once-per-build-session`.

Make flags `-fmodules-validate-system-headers` and
`-fmodules-validate-once-per-build-session` orthogonal, so they have
their own independent responsibilities - if system headers should be
validated and how often.

rdar://87988889

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

This patch takes the first step towards a more principled modeling of undefined behavior in MLIR as discussed in the following discourse threads:

 1. https://discourse.llvm.org/t/semantics-modeling-undefined-behavior-and-side-effects/4812
 2. https://discourse.llvm.org/t/rfc-mark-tensor-dim-and-memref-dim-as-side-effecting/65729

This patch in particular does the following:

 1. Introduces a ConditionallySpeculatable OpInterface that dynamically determines whether an Operation can be speculated.
 2. Re-defines `NoSideEffect` to allow undefined behavior, making it necessary but not sufficient for speculation.  Also renames it to `NoMemoryEffect`.
 3. Makes LICM respect the above semantics.
 4. Changes all ops tagged with `NoSideEffect` today to additionally implement ConditionallySpeculatable and mark themselves as always speculatable.  This combined trait is named `Pure`.  This makes this change NFC.

For out of tree dialects:

 1. Replace `NoSideEffect` with `Pure` if the operation does not have any memory effects, undefined behavior or infinite loops.
 2. Replace `NoSideEffect` with `NoSideEffect` otherwise.

The next steps in this process are (I'm proposing to do these in upcoming patches):

 1. Update operations like `tensor.dim`, `memref.dim`, `scf.for`, `affine.for` to implement a correct hook for `ConditionallySpeculatable`.  I'm also happy to update ops in other dialects if the respective dialect owners would like to and can give me some pointers.
 2. Update other passes that speculate operations to consult `ConditionallySpeculatable` in addition to `NoMemoryEffect`.  I could not find any other than LICM on a quick skim, but I could have missed some.
 3. Add some documentation / FAQs detailing the differences between side effects, undefined behavior, speculatabilty.

Reviewed By: rriddle, mehdi_amini

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

- store NestedNameSpecifier & Loc for the qualifiers
  This information was entirely missing from the AST.
- expose the location information for qualifier/identifier/typedefs as typeloc
  This allows many traversals/astmatchers etc to handle these generically along
  with other references. The decl vs type split can help preserve typedef
  sugar when https://github.com/llvm/llvm-project/issues/57659 is resolved.
- fix the SourceRange of UsingEnumDecl to include 'using'.

Fixes https://github.com/clangd/clangd/issues/1283

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

This test shows instcombine failing to remove a alloca and memcpy for
for a constant array that is read with a masked load.

This will be addressed in a subsequent commit.

Pre-commit test cases to show cases when UZP1 (TRUNC, TRUNC) could be
combined into TRUNC (UZP1) (with some proper bit conversions in the middle) to generate more efficient code.

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

Sadly the demangler copies have diverged.  This resyncs them by
a) pulling the meaningful llvm changes into libcxxabi's gold copy.
b) rerunning the sync script.

I notice uses of placement new, which assume the allocator succeeds --
that's incorrect in general, but an orthogonal problem.

Reviewed By: bader

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

Add a check (can be disabled via a flag) that the pipeline we generate is actually parsable.
Can be disabled because we don't expect to handle every pass in -print-pipeline-passes.

Fixes #58280.

Reviewed By: ChuanqiXu

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

This would solve an example from issue #58137 more
generally, but it may require adding a canonicalization
for shift + shift to shift + add.

Implements:
- P2291R3 Add Constexpr Modifiers to Functions to_chars and from_chars for
  Integral Types in <charconv> Header

Reviewed By: #libc, ldionne

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