Reopens #87534.

Breaks multiple bots:
https://lab.llvm.org/buildbot/#/builders/168/builds/20028
https://lab.llvm.org/buildbot/#/builders/74/builds/27773

And reproducer in a61f9fe3.

This reverts commit a61f9fe3.

Fixes the bazel build. Note the addition of the Arith dependency created
duplicate arith enum declarations in the two dialects, so it had to be
spit into its own build rule. This matches what the cmake build does for
this dialect.

Add code to the runtime support library for the SELECTED_CHAR_KIND and
SELECTED_LOGICAL_KIND intrinsic functions. These are usually used with
constant folding in constant expressions, but the are available for use
with dynamic arguments as well.

Lowering support remains to be implemented.

When we rewrite dynamic relocations, there could be cases where they
reference code locations inside functions that were rewritten. When this
happens, we need to precisely map old address to a new one. Until we can
reliably perform the mapping, detect such condition and issue an error
refusing to write a broken binary.

They weren't run before as part of `check-compiler-rt`.

Verified by adding a `EXPECT_TRUE(false)` in both and observing test failure.

Temporary symbols generated for .eh_frame and .debug_line have an empty
name, which appear in .symtab in the presence of RISC-V style linker
relaxation and will not be discarded by ld/objcopy --discard-locals
(-X).

In contrast, GNU assembler's riscv port assigns a fake name ".L0 " (with
a trailing space) to these symbols so that will be discarded by
ld/objcopy --discard-locals.

This patch matches the GNU behavior. Since Clang's RISC-V targets pass
-X to ld, and GNU ld defaults to -X for RISC-V targets, these ".L0 "
symbols will be discarded after linking by default, as expected by
users.

The llvm-symbolizer special case for RISC-V `SF_FormatSpecific` symbols
https://reviews.llvm.org/D98669 needs to be adjusted.

Note: `"":` in assembly currently crashes.

These constructors are no more complicated than any of the other
*SDNode constructors that are already in the header.

Fixes #87561

When debug level logging is enabled (by adding a call to
`Logger::setLogLevel(Logger::Level::Debug)`), the
`TransportInputTest.RequestWithInvalidParams` unit test logs:

```
[18:35:00.565] --> reply:(92)
```

The format string for this log statement is `"--> reply:{0}({1})"`,
where `{0}` is the original request's method name (that is, the method
name of the request being replied to), and `{1}` is the request ID.
However, because the `Reply` class never initializes its `method`
member, `{0}` is always empty. Initializing it results in the (nicer)
log error below:

```
I[18:35:00.565] --> reply:invalid-params-request(92)
```

Because this is only ever logged for now, its not possible to add a test
case for this. Future patches will rely on `method` being initialized,
however, and will add test cases for this path.

Testing for the name of the flexible array member isn't as robust as
testing the FieldDecl pointers.

All of these constructors were creating a SDVTList using an EVT* created
by SDNode::getValueTypeList. This EVT needs to live at least as long as
the SDNode that uses it. To do this, SDNode::getValueTypeList contains
several function scoped static variables that hold the memory for the
EVT. So the EVT lives until global destructors run.

This is problematic since an EVT contains a Type* that points to memory
allocated by an LLVMContext. If multiple LLVMContexts are used that
don't have overlapping lifetimes, we can end up with stale or or
incorrect pointers cached in the EVTs owned by SDNode::getValueTypeList.

I want to try to make the EVTs be owned by SelectionDAG instead. This is
already done for SDVTLists with more than 1 VT. The single value case is
a very old optimizaton that should be re-evaluated. In order to do this,
I need the SDVTLists to be created by SelectionDAG rather than by the
SDNode itself.

This patch doesn't change how the allocation is done yet. It just moves
the code around.

This patch does reduce the number of calls to getVTList since we now
share with the call needed for the SDNode FoldingSet.

Part of fixing #88233.

---------

Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
Co-authored-by: Adam Siemieniuk <adam.siemieniuk@intel.com>

libFuzzer uses std::clamp which was introduced in C++17.

When the `lsp::MessageHandler` processes a request with invalid params
(that is, the "params" JSON sent along with the request does not match
the shape expected by the message handler for the given method), it
replies by sending an error response to the client.

On the other hand, the language server protocol specifies that
notifications must not result in responses. As a result, when the
JSON params accompanying a notification cannot be parsed, no error is
sent back; there is no indication that an error has occurred at all.

This patch adds an error log for that case. Although clients cannot
parse error logs, this at least provides an indication that something
went wrong on the language server side.

These are hardcoded strings that are already present in the data section
of the binary, no need to immediately place them in the ConstString
StringPools. Lots of code still calls `GetBroadcasterClass` and places
the return value into a ConstString. Changing that would be a good
follow-up.

Additionally, calls to these functions are still wrapped in ConstStrings
at the SBAPI layer. This is because we must guarantee the lifetime of
all strings handed out publicly.

This adds a link to an ics file for the LLVM Floating Point WG line in
the Getting Involved page.

These tests were introduced when the Flang driver was originally
incepted. Back then, `flang-new` only supported a handful of basic
options (e.g. `-v`, `-help`, `-E`) and those `-help` tests were used to
guard against Clang options "leaking" into `flang-new -help`.

With the introduction of the concept of "visibility" (see
https://reviews.llvm.org/D157837 and https://reviews.llvm.org/D157151),
these tests are effectively redundant. Also, with the number of flags
growing, these tests are getting rather brittle.

This test will check the mode register in case of constrained floating
point operations.

---------

Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>

This is a preparation to measure the performance impact of
- P2713R1 Escaping improvements in std::format

and its performance improving followup patch.

This change replaces most of the cc1 option checks in the driver test for fast-math option handling. These changes rely on the assumption that the order in which the driver emits floating-point options is stable.
  
The changes also rely on the assumption that the order of prefixes listed on the FileCheck command line is unimportant and that all prefixed checks will be combined and checked as if they were a single prefix. At the time of the change, that worked.

Addresses issue #89709.

Functions getAUTOpcodeForKey() and getPACOpcodeForKey() contain switch
statements without default cases. Resolved by adding a call to
llvm_unreachable() at the end of each function.

---------

Signed-off-by: Troy-Butler <squintik@outlook.com>
Co-authored-by: Troy-Butler <squintik@outlook.com>

Otherwise if you bazel build //... on macOS this fails to build

Locations inside macro expansions have different spelling/expansion
locations. Apply a FIXME to make the libclang function
clang_getSpellingLocation return the right spelling location, and adapt
the testsuite driver code to use the file location rather than the
spelling location to compute source ranges.

Co-authored-by: Matthieu Eyraud <eyraud@adacore.com>

Since all optimizations that use range metadata now also handle range attribute, this patch replaces writes of
range metadata for call instructions to range attributes.

There was a typo in dispatch trampoline.

The HWASan transform currently always uses x20 to pass the shadow base to hwasan_check_memaccess_shortgranules, even if the shadow base is a constant known at compile time (e.g., for Fuchsia, KHWASan, or via -hwasan-mapping-offset).  This patch uses the fixed shadow variant of the hwasan_check_memaccess_shortgranules intrinsic (introduced in https://github.com/llvm/llvm-project/commit/365bddf634993d5ea357e9715d8aacd7ee40c4b5), allowing the shadow base to be materialized inside the memaccess callee.

We currently only support this optimization for AArch64; it is a no-op on other platforms due to lack of support for lowering the intrinsic.

Note: when a binary is instrumented with -hwasan-mapping-offset, it is necessary to specify HWASAN_OPTIONS=fixed_shadow_base=... (see ea991a11) at runtime to ensure the shadow is mapped appropriately.

This makes Zcf imply F and Zcd imply D in RISCVFeatures.td. They
were already implied in RISCISAInfo.cpp.

Some test RUN lines had to be removed because they were testing
that Zcf without F or Zcd without D would reject some instructions.

This PR extracts the existing `scf.forall` to `scf.for` conversion logic
inside a transform op (https://github.com/llvm/llvm-project/pull/65474)
into a standalone function which can be used in other transformations
and adds a `scf-forall-to-for` pass.

The original commit was calling shrinkToUses on an interval for a virtual
register whose def was erased. This fixes it by calling shrinkToUses first
and removing the interval if we erase the old VL def.