toHalfOpenFileRange() already handles translating macro locations to
file locations, and it can provide a better result by knowing about both
ends of the range.

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

Summary:
This patch fixes some issues with building the GPU target manually
without the runtimes bootstrapping build. This fixes the install
directory and sets the default namespace to something more sensible if
not set. Also I got rid of the check on `-mcpu=native`. it was a neat
trick, but CMake in its INFINITE wisdom does not allow you to set link
flags on the compiler flag check. So I just went with the old tool
usage.

Summary:
We already had a special CUDA default that better tracked the state as
of modern CUDA installations. Recently this was bumped up to `sm_52`,
but there was a location that wasn't respecting this. Fix that.

When reference-types feature is enabled, forcing mem2reg unconditionally
even in `-O0` has some problems described in #81575. This uses
RefTypeMem2Local pass added in #81965 instead. This also removes
`IsForced` parameter added in

https://github.com/llvm/llvm-project/commit/890146b19206827bc48ee1ae1dc1534ff2ff18d7
given that we don't need it anymore.

This may still hurt debug info related to reference type variables a
little during the backend transformation given that they are not stored
in memory anymore, but reference type variables are presumably rare and
it would be still a lot less damage than forcing mem2reg on the whole
program. Also this fixes the EH problem described in #81575.

Fixes #81575.

This fixes buildbot failures:
https://lab.llvm.org/buildbot/#/builders/57/builds/33206

If AMD GPUs don't exist when building libomptarget, the early return causes skipping the plugin installation.

Reverts llvm/llvm-project#83259

This broke an integration test on Windows

Clang and some middle-end optimizations may need these helper
functions.

This can reduce some duplications.

llvm-project/lldb/source/Core/Debugger.cpp:107:14:
error: no type named 'DefaultThreadPoolThreadPool' in namespace 'llvm'
static llvm::DefaultThreadPoolThreadPool *g_thread_pool = nullptr;
       ~~~~~~^
1 error generated.

A few notes:
* pr34538.ll has bitrotten.  The original test printed the analysis after transforms in some cases, but this appears to been lost during migration to new pass manager.  Remove the now redundant pass invocations and simplify the test setup.

relate:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645016.html

The base class llvm::ThreadPoolInterface will be renamed
llvm::ThreadPool in a subsequent commit.

This is a breaking change: clients who use to create a ThreadPool must
now create a DefaultThreadPool instead.

In advance of a change which needs to update these.  This batch was the
"easy" ones, I'll be landing the harder set a few a time for easier
review.

Since `llvm.compressstore` and `llvm.expandload` do require memory
access, it's essential for some target to check if alignment is good to
be able to lower them to target-specific instructions

Try to fix https://github.com/llvm/llvm-project/issues/83845


When `std::forward` is invoked in a function, make sure it uses correct
parameter by checking if the bounded `var` equals the parameter.

Co-authored-by: huqizhi <836744285@qq.com>

If the "march" has some extension with version that is not supported, it
returns the error message like: "error: invalid arch name 'some_arch',
unsupported version number 2.0 for extension 'some_arch'", which is not
precise enough, it should return the message that only tells users "the
extension is not supported".

Currently using the command `clang -cc1 -triple riscv64` to compile the
code below:
```
#include <riscv_vector.h>
void foo() {
  vfloat64m1_t f64m1;
}
```
would get the error message "RISC-V type 'vfloat64m1_t' ... requires the
'zve64x' extension"
which is supposed to be "RISC-V type 'vfloat64m1_t' ... requires the
'zve64d' extension".

These are really the same as the f16 (and i16) instructions, but we need
them for any type that can occur.

Reverts llvm/llvm-project#83948

This broke the ASan buildbot:
https://lab.llvm.org/buildbot/#/builders/168/builds/19054/steps/10/logs/stdio

API clients can now set a MachO::HeaderOptions::BuildVersionOpts field to have
MachOPlatform add an LC_BUILD_VERSION load command to the Mach header for each
JITDylib.

No testcase yet. In the future we'll try to add a MachO parser to the ORC
runtime and extra test options to llvm-jitlink for this.

This commit also incidentally fixes a bug in the MachOBuilder class that lead to
a delegation cycle.

We were setting based on whether the FP value is positive/negative, but
we really want to know whether the resulting integer will be treated as
a signed or unsigned value. Since we use SINT_TO_FP to convert the
integer to FP, we should always used signed here.

Without this we convert +2147483648.0 to an integer 0x80000000 and
convert it using sint_to_fp which produces -2147483648.0.

Fixes #84025.

Read .parainstruction section and mark call instructions with ParaSite
annotations.

Clang sets the nonlazybind attribute for certain ObjC features. The
AArch64 SelectionDAG implementation for non-intrinsic calls
(46e36f09) is behind a cl option.

GCC implements -fno-plt for a few ELF targets. In Clang, -fno-plt also
sets the nonlazybind attribute. For SelectionDAG, make the cl option not
affect ELF so that non-intrinsic calls to a dso_preemptable function use
GOT. Adjust AArch64TargetLowering::LowerCall to handle intrinsic calls.

For FastISel, change `fastLowerCall` to bail out when a call is due to
-fno-plt.

For GlobalISel, handle non-intrinsic calls in CallLowering::lowerCall
and intrinsic calls in AArch64CallLowering::lowerCall (where the
target-independent CallLowering::lowerCall is not called).
The GlobalISel test in `call-rv-marker.ll` is therefore updated.

Note: the current -fno-plt -fpic implementation does not use GOT for a
preemptable function.

Link: #78275

Pull Request: https://github.com/llvm/llvm-project/pull/78890

For `LDBL_MANT_DIG == 113` targets the FortranFloat128Math library
is just an interface library that provides sources and compilation
options to be used for building FortranRuntime - there are not extra
dependencies on other libraries, so it can be a part of FortranRuntime,
which helps to avoid extra linking steps in the compiler driver.
Targets with __float128 support in libc will also use this path.
Other targets, where the math support comes from
FLANG_RUNTIME_F128_MATH_LIB,
FortranFloat128Math is built as a standalone static library,
and the compiler driver needs to conduct the linking.

Flang APIs for COMPLEX(16) are just thin C wrappers around
the C math functions. Flang uses C _Complex ABI for passing/returning
COMPLEX values, so the runtime is aligned to this.

This PR implements the frontend for llvm#70100
This PR is part 1 of 2.
Part 2 requires an intrinsic to instructions lowering.


- `Builtins.td` - add an `rcp` builtin
- `CGBuiltin.cpp` - add the builtin to intrinsic lowering
-  `hlsl_intrinsics.h` - add the `rcp`  api
- `SemaChecking.cpp` - reuse frac's sema checks
- `IntrinsicsDirectX.td` - add the llvm intrinsic

The lowering is not distinquishing -2147483648.0 and 2147483648.0.

The architecture of SPIRVEmitIntrinsics is build in such way that every
private method is called by one main function runOnFunction which then
calls private methods. Private member IRB is allocated in runOnFunction
method but it's not freed. Due to that every time when IR function
contains intrinsics to emit, runOnFunction is entered and memory is
leaked on exit. It's especially true when there are two or more IR
functions to emit. IRB is set to nullptr during construction of object
and it's left without pointing resource until runOnFunction is entered.
This also create possibility of simple mistake when private method is
called but there is no resource pointed. Change requires passing
IRBuilder by reference to private methods. The visit* functions create
it's own IRBuilder thus IRB is eliminated from class scope. In addition
there is a small performance improvement because IRBuilder is not
allocated by heap.

The watchOS and tvOS sanitizers do not compile with publicly-available
SDKs, failing on calls such as fork() and posix_spawn(). Updating the
darwin_test_archs test program to include a call to fork() allows cmake
to exclude those platforms when compiling runtimes. This allows public
builds to enable watchOS/tvOS and compile builtins but not sanitizers.