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

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

Add mmap and munmap to the linux aarch64 entrypoint list as the first
user of these syscalls.

Reviewed By: michaelrj

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

We are reusing that logic in the ML implementation.

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

Not all allocation functions are removable if unused.  An example of a non-removable allocation would be a direct call to the replaceable global allocation function in C++.  An example of a removable one - at least according to historical practice - would be malloc.

getNumberOfRegisters takes a ClassID as it's argument. It shouldn't be passed a bool. Assuming the bool meant vector or not, we should call getRegisterClassForType first.

Reviewed By: fhahn

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

Break up the huge function by extracting a class, storing intermediate
state as class members and breaking up the big function into a group
of class methods all at the same level of abstraction.

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

Currently when -fgpu-rdc is specified, HIP toolchain always does host linking even
if --cuda-device-only is specified.

This patch fixes that. Only device linking is performed when --cuda-device-only
is specified.

Reviewed by: Artem Belevich

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

While running heap checker on a test that uses LLDB API, the following memory leak is found:

RAW: HeapChecker started...
RAW: Leak check _main_ detected leaks of 34 bytes in 4 objects
RAW: The 2 largest leaks:
RAW: Leak of 17 bytes in 2 objects allocated from:
@ 0x7fb93bd20166 NewHook()
@ 0x7fb929372a73 absl::base_internal::MallocHook::InvokeNewHookSlow()
@ 0x5600d1046093 libc_malloc
@ 0x7fb974529c03 xmlStrdup
@ 0x7fb9744c2a0b xmlGetProp
@ 0x7fb9749d9ed6 lldb_private::XMLNode::GetAttributeValue()
@ 0x7fb979043001 std::u::function::policy_invoker<>::__call_impl<>()
@ 0x7fb9749da06d lldb_private::XMLNode::ForEachChildElement()
@ 0x7fb97903c54d lldb_private::process_gdb_remote::ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess()
@ 0x7fb97902cfe4 lldb_private::process_gdb_remote::ProcessGDBRemote::GetGDBServerRegisterInfo()
@ 0x7fb97902c1d0 lldb_private::process_gdb_remote::ProcessGDBRemote::BuildDynamicRegisterInfo()
@ 0x7fb97902e92a lldb_private::process_gdb_remote::ProcessGDBRemote::SetThreadStopInfo()
@ 0x7fb97902db18 lldb_private::process_gdb_remote::ProcessGDBRemote::DoConnectRemote()
@ 0x7fb97584965e lldb_private::Process::ConnectRemote()
@ 0x7fb975839fa6 lldb_private::Platform::DoConnectProcess()
@ 0x7fb97583a39e lldb_private::Platform::ConnectProcessSynchronous()
@ 0x7fb97545b28b CommandObjectProcessConnect::DoExecute()
@ 0x7fb9755a70c9 lldb_private::CommandObjectParsed::Execute()
@ 0x7fb97559c0e9 lldb_private::CommandInterpreter::HandleCommand()
@ 0x7fb975460145 lldb_private::CommandObjectRegexCommand::DoExecute()
@ 0x7fb9755a72d2 lldb_private::CommandObjectRaw::Execute()
@ 0x7fb97559c0e9 lldb_private::CommandInterpreter::HandleCommand()
@ 0x7fb997a5f22e lldb::SBCommandInterpreter::HandleCommand()
@ 0x7fb997a5ef9b lldb::SBCommandInterpreter::HandleCommand()

This change fixes the memory leaks by freeing memory after it is no
longer in use. Tested with "ninja check-lldb".

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

When the unroll factor is 1, we should only fail "unrolling" when the trip count also is determined to be 1 and it is unable to be promoted.

Reviewed By: bondhugula

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

Use `_LIBCPP_DEBUG_ASSERT` in `<list>`

Reviewed By: Quuxplusone, ldionne, #libc

Spies: libcxx-commits

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

Some types need to be 64 bit. Unsigned long is a hazard there.

Reviewed By: arsenm

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

... by examining `_MSVC_EXECUTION_CHARACTER_SET` in the force-include header.

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

This commit fixes a missed opportunity in merging consecutive stores.
The code that searches for stores skipped the case of stores that
directly connect to the root. The comment above the implementation lists
this case but the code did not handle it. I found this pattern when
looking into the shared_ptr destructor. GCC generates the right
sequence. Here is a small repo:

    int foo(int* buff) {
        buff[0] = 0;
        int x = buff[1];
        buff[1] = 0;
        return x;
    }

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

Fix the module build after 2c0fb962

@phosek mentioned others might want it reST for consistency. As I
personally do not like Markdown at all and just did the "usual GitHub
read-me thing" out of habit, I am more than happy to oblige.

Also fix the typos found in the original.

Reviewed By: phosek, lebedev.ri

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

That will make it easier to change the behavior of the arc4random()
based implementation. Note that in particular, the eval.pass.cpp test
used to work with non "/dev/random" based implementations because we'd
throw an exception upon constructing the random_device. This patch makes
the intent of the test clearer.

This is created on analogy with the other CACHE PATHs in this package,
and other `*_INSTALL_INCLUDE_DIR` in other packages.

The branching is adjusted to deduplicate some existing code, and
likewise avoid having to define this new variable more than once.

This will be used for D99484.

Reviewed By: #libunwind, compnerd

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

The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

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

Use the zx_clock_get_monotonic system call directly rather than
going through the POSIX clock_gettime function.  The libc function
is a trivial wrapper around the system call, and is not a standard C
function.  Avoiding it reduces the Fuchsia libc ABI surface that
libc++ depends on.

Reviewed By: phosek, ldionne, #libc

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

The NFC part of D116958. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

This patch simplifies the interface between RAGreedy and the eviction
adviser by passing the allocator to the adviser, which allows the latter
to extract needed information as needed, rather than requiring it be passed
piecemeal at construction time (which would also complicate later
evolution).

Part of this, the patch also moves ExtraRegInfo back to RAGreedy. We
keep the encapsulation of ExtraRegInfo because it has benefits (e.g.
improved readability by abstracting access to the cascade info) and also
simpler re-initialization at regalloc pass re-entry time (we just flush
the Optional).

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

I recently had an email exchange on flang-dev that revealed that the
documentation on how to build flang is incorrect.  This update fixes
that.

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

rdar://86776155

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

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

This code is intended to give a special exception for platforms which set errno in some math functions but not fma. This does not apply to Android, which does not set errno in any math functions (https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/math.h;drc=master;l=59). The correct implementation for Android is to set -fno-math-errno by default, which was done in https://reviews.llvm.org/D51068. Therefore, this special exception is no longer needed for Android. Deleting it slightly reduces code complexity, clang executable size, compile time, and test time.

This reverts fbfba29d.

Reviewed By: pirama

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

We were trying to guess at the original IR type for image intrinsics
after legalization to figure out if they were d16, but this didn't
work. Explicitly track if this is a d16 operation or not in the
opcode, as is done for the buffer intrinsics.

The OpenCL library is using f32 image writes with a dmask of 15 for
some reason, and this was incorrectly switching them to use d16. Fixes
image failures in the OpenCL conformance test. The equivalent dmask
for loads doesn't even select in either selector.

This diff enables users to override CMAKE_C_ARCHIVE_CREATE & CMAKE_CXX_ARCHIVE_CREATE
(currently set in HandleLLVMOptions.cmake).

For example, one can specify
cmake -DCMAKE_C_ARCHIVE_CREATE="<CMAKE_AR> TDqc <TARGET> <LINK_FLAGS> <OBJECTS>" \
      -DCMAKE_CXX_ARCHIVE_CREATE="<CMAKE_AR> TDqc <TARGET> <LINK_FLAGS> <OBJECTS>" ...
to make the build create thin archives instead of regular ones.
For a clean run `ninja lld` using thin archives seems to reduce the size
of the build directory from ~14GB to ~8GB

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

Fixes crash in assertion about dropping debug info.

This behavior was fixed for regular identifiers in
9f3edc32, but the same fix was not applied to
macro fixits. This addresses https://github.com/llvm/llvm-project/issues/52895.

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

If we know the source is a valid object, we do not need to insert a
null check. This misses a lot of opportunities from
metadata/attributes not tracked in codegen.

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

This tests have recently become flaky (flakier?) causing occasional failures in the windows lldb buildbot

Currently, something like `print *, size(foo(n,m))` was rewritten
to `print *, size(foo_result_symbol)` when foo result is a non constant
shape array. This cannot be processed by lowering or reprocessed by a
Fortran compiler since the syntax is wrong (`foo_result_symbol` is
unknown on the caller side) and the arguments are lost when they might
be required to compute the result shape.

It is not possible (and probably not desired) to make GetShape fail in
general in such case since returning nullopt seems only expected for
scalars or assumed rank (see GetRank usage in lib/Semantics/check-call.cpp),
and returning a vector with nullopt extent may trigger some checks to
believe they are facing an assumed size (like here in intrinsic argument
checks: https://github.com/llvm/llvm-project/blob/196204c72c68a577c72af95d70f18e3550939a5e/flang/lib/Evaluate/intrinsics.cpp#L1530).

Hence, I went for a solution that limits the rewrite change to folding
(where the original expression is returned if the shape depends on a non
constant shape from a call).

I added a non default option to GetShapeHelper that prevents the rewrite
of shape inquiry on calls to descriptor inquiries. At first I wanted to
avoid touching GetShapeHelper, but it would require to re-implement all
its logic to determine if the shape comes from a function call or not
(the expression could be `size(1+foo(n,m))`). So added an alternate
entry point to GetShapeHelper seemed the cleanest solution to me.

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

We only support both TLSDESC and TLS GD for x86 so this is an x86-specific
problem. If both are used, only one R_X86_64_TLSDESC is produced and TLS GD
accesses will incorrectly reference R_X86_64_TLSDESC. Fix this by introducing
SymbolAux::tlsDescIdx.

Reviewed By: ikudrin

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

As discussed in https://github.com/llvm/llvm-project/issues/53020 / https://reviews.llvm.org/D116692,
SCEV is forbidden from reasoning about 'backedge taken count'
if the branch condition is a poison-safe logical operation,
which is conservatively correct, but is severely limiting.

Instead, we should have a way to express those
poison blocking properties in SCEV expressions.

The proposed semantics is:
```
Sequential/in-order min/max SCEV expressions are non-commutative variants
of commutative min/max SCEV expressions. If none of their operands
are poison, then they are functionally equivalent, otherwise,
if the operand that represents the saturation point* of given expression,
comes before the first poison operand, then the whole expression is not poison,
but is said saturation point.
```
* saturation point - the maximal/minimal possible integer value for the given type

The lowering is straight-forward:
```
compare each operand to the saturation point,
perform sequential in-order logical-or (poison-safe!) ordered reduction
over those checks, and if reduction returned true then return
saturation point else return the naive min/max reduction over the operands
```
https://alive2.llvm.org/ce/z/Q7jxvH (2 ops)
https://alive2.llvm.org/ce/z/QCRrhk (3 ops)
Note that we don't need to check the last operand: https://alive2.llvm.org/ce/z/abvHQS
Note that this is not commutative: https://alive2.llvm.org/ce/z/FK9e97

That allows us to handle the patterns in question.

Reviewed By: nikic, reames

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

Before this patch, the user needed to specialize both of
`is_placeholder<MyType>` and `is_placeholder<const MyType>`.
After this patch, only the former is needed (although the
latter is harmless if provided).

The new tests don't actually fail unless return type deduction
is used, which is a C++14 feature. Specializing `is_placeholder`
is still allowed in C++11, though.

Fixes #51095.

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