These macros are defined in avr-gcc and are useful when working with
assembly. For example, startup code needs to copy the contents of .data
from flash to RAM, but should use elpm (instead of lpm) on devices with
more than 64kB flash. Without __AVR_HAVE_ELPM__, there is no way to know
whether the elpm instruction is supported.

This partially fixes https://github.com/llvm/llvm-project/issues/56157.

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

Reviewed By: aartbik

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

Reviewed By: aartbik

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

Reviewed By: aartbik

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

Now, there's a big caveat here - these bytes
are abstract bytes, not the i8 we have in LLVM,
so strictly speaking this is not exactly legal,
see e.g. https://github.com/AliveToolkit/alive2/issues/860
^ the "bytes" "could" have been a pointer,
and loading it as an integer inserts an implicit ptrtoint.

But at the same time,
InstCombine's `InstCombinerImpl::SimplifyAnyMemTransfer()`
would expand a memtransfer of 1/2/4/8 bytes
into integer-typed load+store,
so this isn't exactly a new problem.

Note that in memory, poison is byte-wise,
so we really can't widen elements,
but SROA seems to be inconsistent here.

Fixes #59116.

Looks like std::conditional wasn't included in 14d48692
(& maybe other typedefs that should be using this technique either got
missed or have regressed since that change was made)

This was noticed by a 1.4% clang.dwp regression due to
f4fb72e6 introducing more instantiations
of std::conditional - this change reduces that regression to 0.6% at
least.

I'm also looking at other instantiations caused by that change that
might be able to be addressed - but a quick grep shows ~200 "type"
typedefs missing _LIBCPP_NODEBUG, so maybe a systematic application of
the typedef might be suitable?

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

The existing behaviors and callbacks were overlapping and had very
confusing semantics: beginBasicBlock/endBasicBlock were not always
called, beginFragment/endFragment seemed like they were meant to mean
the same thing, but were slightly different, etc. This resulted in
confusing semantics, virtual method overloads, and control flow.

Remove the above, and replace with new beginBasicBlockSection and
endBasicBlockSection callbacks. And document them.

These are always called before the first and after the last blocks in
a function, even when basic-block-sections are disabled.

The KCFI sanitizer emits "kcfi" operand bundles to indirect
call instructions, which the LLVM back-end lowers into an
architecture-specific type check with a known machine instruction
sequence. Currently, KCFI operand bundle lowering is supported only
on 64-bit X86 and AArch64 architectures.

As a lightweight forward-edge CFI implementation that doesn't
require LTO is also useful for non-Linux low-level targets on
other machine architectures, add a generic KCFI operand bundle
lowering pass that's only used when back-end lowering support is not
available and allows -fsanitize=kcfi to be enabled in Clang on all
architectures.

This relands commit eb2a57eb with
fixes.

Reviewed By: nickdesaulniers, MaskRay

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

Reviewed By: aartbik

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

AIX uses LIBPATH to specify the library search path in addition to
LD_LIBRARY_PATH, and a lot of users / tooling will use it
preferentially. In lit we currently pass through LD_LIBRARY_PATH but not
LIBPATH in the env on AIX, this patch corrects this inconsistency.

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

This patch adds a new runToBinaryEntry option which sets a one-shot breakpoint
at program entry. This option is useful for synchronizing module loading with
dynamic loader to measure debugger startup performance:  when program entry
one-short breakpoint hits most of the dependency modules should have been
loaded so this provides a good sample point for debugger startup time.

More explicitly for lldb-vscode, when this option is enabled, "Initialized" DAP
event is synchronously sent after most dependency modules are loaded.

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

This reverts commit 34108082 with fixes.

Breaks build of LLVMgold here:
```
/repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1108:19: error: no matching function for call to 'localCache'
    Cache = check(localCache("ThinLTO", "Thin", options::cache_dir, AddBuffer));
                  ^~~~~~~~~~
/repositories/llvm-project/llvm/include/llvm/Support/Caching.h:72:21: note: candidate function not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1102:20)' to 'llvm::AddBufferFn' (aka 'function<void (unsigned int, const llvm::Twine &, std::unique_ptr<MemoryBuffer>)>') for 4th argument
Expected<FileCache> localCache(
                    ^
/repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1110:18: error: no viable conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'llvm::AddStreamFn' (aka 'function<Expected<std::unique_ptr<CachedFileStream>> (unsigned int, const llvm::Twine &)>')
  check(Lto->run(AddStream, Cache));
                 ^~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:375:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::nullptr_t' for 1st argument
      function(nullptr_t) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:386:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'const std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream>> (unsigned int, const llvm::Twine &)> &' for 1st argument
      function(const function& __x)
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:404:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream>> (unsigned int, const llvm::Twine &)> &&' for 1st argument
      function(function&& __x) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:435:2: note: candidate template ignored: requirement '_Callable<(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &, (lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20), std::__invoke_result<(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &, unsigned int, const llvm::Twine &>>::value' was not satisfied [with _Functor = (lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &]
        function(_Functor&& __f)
        ^
/repositories/llvm-project/llvm/include/llvm/LTO/LTO.h:278:25: note: passing argument to parameter 'AddStream' here
  Error run(AddStreamFn AddStream, FileCache Cache = nullptr);
                        ^

```

This reverts commit 387620aa.

The lowercase `__ppc64__` is not defined by non-darwin powerpc64 GCC, therefore
it lures users to write code which is not portable to GCC. Migrate to
`__powerpc64__` in preparation for undefining `__ppc64__`. `__powerpc64__` is
much more common than `__PPC64__`.

Update alignment_of.pass.cpp to use 1 unconditionally:
on powerpc-unknown-linux-gnu `alignof(bool) = _Alignof(bool) = __alignof(bool) = 1`.
The value 4 might be derived from an ancient Clang.

Change is_iec559 to true when long double uses uses IEEE 754 quadruple or double
precision (i.e. not ibm128).

Reviewed By: #libc, thesamesam, ldionne

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

as this is failing on the build bots:

https://lab.llvm.org/buildbot/#/builders/214/builds/4442/steps/6/logs/FAIL__Clang__hidden-duplicates_m

and is being investigate under https://reviews.llvm.org/D130327.

This rectifies a FIXME that dates all the way back
to 2014 about not doing so due to the backend issues.

Presumably sufficient amount of time has passes
and all the known issues have been addressed,
or at least we will find out of there are some left...

As it has been established previously by precedent,
if we see a pointer type, then that is the type we must use.
Essentially, we don't want to introduce `inttoptr`'s.

_TLS_MODULE_BASE_ is supposed to be defined by the final link. Defining it in a
relocatable link may render the final link value incorrect.

GNU ld i386/x86-64 have the same issue: https://sourceware.org/bugzilla/show_bug.cgi?id=29820

Adds InitListExpr case in format string checks.

e.g.

    int sprintf(char *__restrict, const char * __restrict, ...);

    int foo()
    {
        char data[100];
        constexpr const char* fmt2{"%d"};  // no-warning
        sprintf(data, fmt2, 123);
    }

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

Reviewed By: aaron.ballman

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

This symbol is supposed to be defined by the final executable link. The new
behavor matches GNU ld.

We don't provide __extendhfxf2, and only have the soft-float
__extendhfsf2 in compiler-rt.  This only changed recently with
655ba9c8, so this patch reverts back to the previous behavior.

However, the f80->f16 fptrunc is not easily implementable without
the compiler-rt __truncxfhf2, but that has always been true, and
isn't an immediate regression.

Patch by Ahmed Bougacha.

rdar://102194995

Fixes issue [59091](https://github.com/llvm/llvm-project/issues/59091).

`CodeRegionGenerator::parseCodeRegions` is implemented by `AsmCodeRegionGenerator`.
If it were to be implemented in `AnalysisRegionGenerator` or `InstrumentRegionGenerator`,
then `parseCodeRegions` from an `AsmAnalysisRegionGenerator` or `AsmInstrumentRegionGenerator`
object would be ambiguous. To solve this, `AsmAnalysisRegionGenerator` and
`AsmInstrumentRegionGenerator` qualify their call to `AsmCodeRegionGenerator::parseCodeRegions`.

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

This was previously guarded by HAS_THREAD_LOCAL, which was never set by
CMake and had to be specified manually. Android has been setting this to
solve https://github.com/android/ndk/issues/1200 [1], but every compiler
and platform libc++abi supports should have thread_local by now, so we
can just get rid of the fallback implementation and simplify things
significantly (including removing the now unused fallback calloc).

[1] https://android-review.googlesource.com/c/toolchain/llvm-project/+/1285596

Reviewed By: #libc_abi, MaskRay, ldionne

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

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

Use after free found by asan.

Leaves the implementation and tests files in-place for right now, but
deletes the ability to build the old sanitizer-common based scudo. This
has been on life-support for a long time, and the newer scudo_standalone
is much better supported and maintained.

Also patches up some GWP-ASan wording, primarily related to the fact
that -fsanitize=scudo now is scudo_standalone, and therefore the way to
reference the GWP-ASan options through the environment variable has
changed.

Future follow-up patches will delete the original scudo, and migrate all
its tests over to be part of the scudo_standalone test suite.

Reviewed By: vitalybuka

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

This reverts commit 01023bfc. The extended test now triggers undefined behavior:
```
/b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp:577:41: runtime error: load of value 180, which is not a valid value for type 'bool'
    #0 0xaaaae3333a30 in hasCFGChanged /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp:577:41
    #1 0xaaaae3333a30 in llvm::ObjCARCOptPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp:2494:26
    ...
```

and prepare for __global_pointer$ and _TLS_MODULE_BASE_ fix.

ControlHeightReduction (CHR) clones the code region to reduce the
branches in the hot code path. The number of clones is linear to the
depth of the region.

Currently it does not have control over the code size increase. We are
seeing one ~9000 BB functions get expanded to ~250000 BBs, an 25x
increase. This creates a big compile time issue for the downstream
optimizations.

This patch adds a cap for number of clones for one region.

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

Reviewed By: ldionne, Mordante, #libc

Spies: EricWF, libcxx-commits

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits

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