On Linux crt is typically use in combination with builtins. In the Clang
driver the use of builtins and crt is controlled by the --rtlib option.
Both builtins and crt also have similar build requirements where they
need to be built before any other runtimes and must avoid dependencies.
We also want builtins and crt these to be buildable separately from the
rest of compiler-rt for bootstrapping purposes. Given how simple crt is,
rather than maintaining a separate directory with its own separate build
setup, it's more efficient to just move crt into builtins. We still use
separate CMake option to control whether to built crt same as before.

This is an alternative to D89492 and D136664.

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

This allows us to pass in a memory buffer directly simplifying usage
downstream.

Reviewed By: tejohnson

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

Removing the rounding mode arguments seems like more trouble than
it's worth. minimum and maximum are still broken.

https://reviews.llvm.org/D154994

Ideally the normal fadd/fmin/fmax this was creating would fail the verifier.
It's probably also necessary to force off FP exception handlers in the cmpxchg
loop but we don't have a generic way to do that now.

Note strictfp builder is broken in the minnum/maxnum case

https://reviews.llvm.org/D154993

Avoid diffs from no longer hardcoding metadata checks

Annotation attributes may be attached to a function to mark it with
custom data that will be contained in the final Wasm file. The
annotation causes a custom section named
"func_attr.annotate.<name>.<arg0>.<arg1>..." to be created that will
contain each function's index value that was marked with the annotation.

A new patchable relocation type for function indexes had to be created so
the custom section could be updated during linking.

Reviewed By: sbc100

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

Revert "[lldb-vscode] Creating a new flag for adjusting the behavior of evaluation repl expressions to allow users to more easily invoke lldb commands."

This reverts commit 16317f1c.

Reverting because of test failures:

******************** TEST 'lldb-api :: tools/lldb-vscode/console/TestVSCode_console.py' FAILED ********************
Script:
--
/usr/local/Frameworks/Python.framework/Versions/3.10/bin/python3.10 /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS --codesign-identity lldb_codesign --env LLVM_LIBS_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./lib --env LLVM_INCLUDE_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/include --env LLVM_TOOLS_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin --libcxx-include-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/include/c++/v1 --libcxx-library-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib --arch x86_64 --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex --lldb-module-cache-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-lldb/lldb-api --clang-module-cache-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-api --executable /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/lldb --compiler /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/clang --dsymutil /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/dsymutil --llvm-tools-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin --lldb-libs-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./lib --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex -t --env TERM=vt100 /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/tools/lldb-vscode/console -p TestVSCode_console.py

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/57586/

The unified LTO pipeline creates a single LTO bitcode structure that can
be used by Thin or Full LTO. This means that the LTO mode can be chosen
at link time and that all LTO bitcode produced by the pipeline is
compatible, from an optimization perspective. This makes the behavior of
LTO a bit more predictable by normalizing the set of LTO features
supported by each LTO bitcode file.

Example usage:

  # Compile and link. Select regular LTO at link time.
  clang -flto -funified-lto -fuse-ld=lld foo.c

  # Compile and link. Select ThinLTO at link time.
  clang -flto=thin -funified-lto -fuse-ld=lld foo.c

  # Link separately, using ThinLTO.
  clang -c -flto -funified-lto foo.c  # -flto={full,thin} are identical in
  terms of compilation actions
  clang -flto=thin -fuse-ld=lld foo.o  # pass --lto=thin to ld.lld

  # Link separately, using regular LTO.
  clang -c -flto -funified-lto foo.c
  clang -flto -fuse-ld=lld foo.o  # pass --lto=full to ld.lld

The RFC discussing the details and rational for this change is here:
https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774

The declared attributes for recognized intrinsics do not matter and
are ignored. Split this test into a normal memcpy which is never
convergent, and one that uses an unrecognized convergent intrinsic
declaration.

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

This diff makes findDealloc return nullopt if the list of users contains "realloc".
Fixes https://github.com/llvm/llvm-project/issues/60726
(In particular, in SimplifyClones (uses findDealloc) treating "realloc" as "dealloc"
breaks the assumption that "dealloc" has no users)

Test plan: ninja check-mlir check-all

Differential revision: https://reviews.llvm.org/D154892

This test relies on MSVC style linking details, such as -Wl,-dll
(which could be expressed with just "-shared", which would work
with MinGW too) and an implicitly created import library named
"<basename>.lib" (which isn't created when linking in MinGW mode).

This fixes running the compiler-rt tests in MinGW environments.

Fix build breakage from https://reviews.llvm.org/D154272.
(I accidentally dropped the fix when I relanded the patch.)

The diff adds a library and header for clangd main function. That change allows to create custom builds for clangd outside the main LLVM repo. The diff also allows to use build system different from CMake to build clangd. The main reason for such change is an ability to use custom clang-tidy modules (created outside LLVM repo).

Test Plan:
```
ninja clangd
```
also check that necessary libs are installed aka
```
ninja install
...
ls <install folder>/lib/libclangdMain.a
```

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

In 64 bit mode, any references to symbols that might end up autoimported
must be made via full 64 bit pointers (usually in .refptr stubs
generated by the compiler).

If referenced via e.g. a 32 bit rip relative offset, it might work
as long as DLLs are loaded close together in the 64 bit address
space, but will fail surprisingly later if they happen to be loaded
further apart. Any cases of that happening is usually a toolchain
error, and the sooner we can warn about it, the easier it is to diagnose.

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

Summary:
This pointer was not initliazed to null which meant that it would be
erronenously deleted by plugins that were not in use.

This patch is a following for the previous patch https://reviews.llvm.org/D151519.
With this patch, vector.load op with narrow bitwidth (e.g., i4) can be converted to
supported wider bitwidth (e.g., i8).

Reviewed By: hanchung

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

[lldb-vscode] Creating a new flag for adjusting the behavior of evaluation repl expressions to allow users to more easily invoke lldb commands.

This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.

When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:

* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.

Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide auto-completes.

RFC Discussion: https://discourse.llvm.org/t/rfc-lldb-vscode-evaluate-repl-behavior-and-improvements/71667

Reviewed By: wallace

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

Reviewed By: rnk

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

We should merge two top TransferBatches so that the range marking can be
done correctly

This reverts commit 57ae8a2a.

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

To complement the bf16 expansion and truncation patterns added to
ExpandOps, define a pass that replaces, for any arithmetic operation
op,
%y = arith.op %v0, %v1, ... : T
with
%e0 = arith.expf %v0 : T to U
%e1 = arith.expf %v1 : T to U
...
%y.exp = arith.op %e0, %e1, ... : U
%y = arith.truncf %y.exp : U to T

This allows for "emulating" floating-point operations not supported on
a given target (such as bfloat operations or most arithmetic on 8-bit
floats) by extending those types to supported ones, performing the
arithmetic operation, and then truncating back to the original
type (which ensures appropriate rounding behavior).

The lowering of the extf and truncf ops introduced by this
transformation should be handled by subsequent passes.

Reviewed By: rsuderman

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

This restores commit b4a82b62, reverted
in 3ab7ef28 because it was thought to
cause a bot failure, which ended up being unrelated to this patch set.

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

This restores commit 29252fdd, reverted
in 3498cf52 because it was thought to
cause a bot failure, which ended up being unrelated to this patch set.

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

Relanding with #if SANITIZER_GLIBC to avoid breaking FreeBSD.
Also incorporates Arthur's BUILD.gn fix (thanks!) from https://reviews.llvm.org/rGc1e283851772ba494113311405d48cfb883751d1

Original commit message:
This patch adds an msan interceptor for dladdr1 (with support for RTLD_DL_LINKMAP and RTLD_DL_SYMENT) and an accompanying test. It also adds a helper file, msan_dl.cpp, that contains UnpoisonDllAddrInfo (refactored out of the dladdr interceptor) and UnpoisonDllAddr1ExtraInfo.

Reviewed By: vitalybuka

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

Do not look for the global early in nullify codegen. The type descriptor
can be emitted later and it would raise an error as it could not be found.
Use `fir.type_desc` instead so it delays the type descriptor lookup until
evrything is emitted.

https://github.com/llvm/llvm-project/issues/63775

Reviewed By: vzakhari

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

Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.

Fixes #63682

Reviewed By: aaron.ballman, #clang-language-wg

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

This ensures that if someone calls the `rpc_shutdown` method multiple
times it will not segfault and gracefully continue. This was causing
problems in the OpenMP usage. This could point to other issues, but for
now this is a safe fix.

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

I need to call this to figure out why the assert in
StopInfoMachException::CreateStopReasonWithMachException is triggering, but
it isn't appropriate to directly access the GDBRemoteCommunication there.  And
dumping whatever history the process plugin has collected during the run isn't
gdb-remote specific...

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

Extended BPFCheckAndAdjustIR pass with sinkMinMax() transformation
that undoes LICM hoistMinMax pass.

The undo transformation converts the following patterns:

    x < min(a, b) -> x < a && x < b
    x > min(a, b) -> x > a || x > b
    x < max(a, b) -> x < a || x < b
    x > max(a, b) -> x > a && x > b

Where 'a' or 'b' is a constant.
Also supports `sext min(...) ...` and `zext min(...) ...`.

~~~

This was previously commited as 09feee55 and reverted in
0bf9bfea because of the testbot memory leak report:
  https://lab.llvm.org/buildbot/#/builders/5/builds/34931

The memory leak issue was caused by incorrect instruction removal
sequence in skinMinMaxBB():

    I->dropAllReferences();  -------->  I->eraseFromParent();
    I->removeFromParent();   fixed to

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

This is part of the process to remove vector.insertelement/extractelement
from the Vector dialect.

RFC: https://discourse.llvm.org/t/rfc-psa-remove-vector-extractelement-and-vector-insertelement-ops-in-favor-of-vector-extract-and-vector-insert-ops

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

If MatchesAnyListedNameMatcher::NameMatcher::match() is called in
MatchMode::MatchUnqualified mode with a NamedDecl that has no name then
calling NamedDecl::getName() will assert with:
 `Name.isIdentifier() && "Name is not a simple identifier"'

It seems unfair to force all matchers using
matchers::matchesAnyListedName to defend against this, particularly
since test cases are unlikely to provoke the problem. Let's just check
whether the identifier has a name before attempting to use it instead.

Add test case that reproduces the problem to the
use-std-print-custom.cpp lit check.

Reviewed By: PiotrZSL

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