When set to non-zero, the HWASan runtime will map the shadow base at the
specified constant address.

This is particularly useful in conjunction with the existing compiler
option
'hwasan-mapping-offset', which bakes a hardcoded constant address into
the instrumentation.

---------

Co-authored-by: Thurston Dang <thurston@google.com>

WG14 N2939 (Identifier Syntax Fixes) corrects a grammar issue in the C
standard but does not otherwise change intended behavior. This change
updates the C23 status to note this paper as implemented as of Clang 15;
the release in which support for N2836 (Identifier Syntax using Unicode
Standard Annex 31) was implemented.

Currently we are missing set up-boundary address for FinalArraySection
as highests elements in partial struct data.

Currently for:
\#pragma omp target map(D.a) map(D.b[:2])
The size is:
  %a = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 0
  %b = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 1
  %arrayidx = getelementptr inbounds [2 x float], ptr %b, i64 0, i64 0
  %2 = getelementptr float, ptr %arrayidx, i32 1
  %3 = ptrtoint ptr %2 to i64
  %4 = ptrtoint ptr %a to i64
  %5 = sub i64 %3, %4
%6 = sdiv exact i64 %5, ptrtoint (ptr getelementptr (i8, ptr null, i32
1) to i64)

Where %2 is wrong for (D.b[:2]) is pointer to first element of array
section. It should pointe to last element of array section.
  
The fix is to emit the pointer to the last element of array section and
use this pointer as the highest element in partial struct data.

After change IR:
  %a = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 0
  %b = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 1
  %arrayidx = getelementptr inbounds [2 x float], ptr %b, i64 0, i64 0
  %b1 = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 1
  %arrayidx2 = getelementptr inbounds [2 x float], ptr %b1, i64 0, i64 1
  %1 = getelementptr float, ptr %arrayidx2, i32 1
  %2 = ptrtoint ptr %1 to i64
  %3 = ptrtoint ptr %a to i64
  %4 = sub i64 %2, %3
%5 = sdiv exact i64 %4, ptrtoint (ptr getelementptr (i8, ptr null, i32
1) to i64)

rdar://79874441

AlignmentFromAssumptions uses SCEV to update the load/store alignment.
It tracks down the use-def chains for the pointer which it takes from
the assumption cache until it reaches the load or store instruction. It
mistakenly adds to the worklist the users of the load result
irrespective of the fact that the load result has no connection with the
original pointer, moreover, it is not a pointer at all in most cases.
Thus the def-use chain contains irrelevant load users. When it is a
store instruction the algorithm attempts to adjust its alignment to the
alignment of the original pointer. The problem appears when the load and
store memory operand pointers belong to different address spaces and
possibly have different sizes.
The 4bf015c0 was an attempt to address a
similar problem. The truncation or zero extension was added to make
pointers the same size. That looks strange to me because the z...

Patch by: Kerry McLaughlin <kerry.mclaughlin@arm.com>

Not that I'm very good at SFINAE, but it seems that conversion operators
are
perhaps difficult to compose with SFINAE. I saw an example that used one
layer
of indirection to have an explicit return type that could then be used
with
enable_if_t.

Link: https://stackoverflow.com/a/7604580
Fixes: #74623

If the module summary references a global variable that does not
exist, throw a nice error instead of asserting.

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

The specific terminator operation depends on what operation it is inside
of. The function `genOpenMPTerminator` performs these checks and selects
the appropriate type of terminator.

Remove partial duplication of that code, and replace it with a function
call. This makes `genOpenMPTerminator` be the sole source of OpenMP
terminators.

This adds test coverage for conditions with and/or.

If we're extracting a constant floating point value, and the constant is a legal fp imm value, then replace the extraction with a fp constant.

Add a pre-commit CI workflow for the experimental SPIR-V backend. This
action should only run when SPIR-V target or test files are modified.
The `codegen-spirv` tests don't run as part of `check-all` because the
SPIR-V backend is still experimental.

Depends on #73371 (for a green tree)

Remove references to functions that were deleted in #74521 which are
causing SPIR-V backend build failures.

Add proper explanation for cin.sh.cpp fail.
The stdin-is-piped.sh.cpp used to fail with old qemu (4.2.0), but should
pass now, as the qemu is updated now to 8.1.3 in CI.

Summary:
This was added in a previous patch to update how we export the static
library used for OpenMP offloading. By mistake this if-else was using
the output incorrectly.

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

'isctype' fails in arm64-big-endian because the __regex_word involved
in mask operation is not changed based on the platform endianness, while
the character mask does change.

Fixes #62433

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

When I originally added this fold, it did not actually fix my
motivation case, where the add was represented as an or. Now that
we have the disjoint flag this can finally be cleanly supported.

This matches either a plain "add" or an "or disjoint" that can
be converted into an add. The AddLike terminology is adopted from
the SDAG layer.

Replace explicit calls to
```
  op = builder.create<SectionOp>(...)
  createBodyOfOp<SectionOp>(op, ...)
```
with a single call to
```
  createOpWithBody<SectionOp>(...)
```

This is NFC, that's what the `createOpWithBody` function does.

This test contains an annoying mix of generated and hand-written
check lines. Generate the whole test.

This code was added 17 years ago but never enabled or tested. GCC warns
that -I- is deprecated for them, and Clang gives an error when passed
-I-, so we may as well remove this code rather than hook it up to the
driver and maintain it.

I'm not sure whether it's possible to cause a miscompile due to
the missing check right now, as the affected values mechanism
effectively protects us against this. This becomes a problem for
an upcoming patch though.

Mark ISD::SETCC node as legal, and add handling for the vector types
condition codes.

Test was failing due to a different transform sequence declaration (transform sequence were used, while now it should be named transform sequence). Test is now fixed.

lld string tail merging interacts badly with ASAN on Windows, as is
reported in https://github.com/llvm/llvm-project/issues/62078.
A similar error was found when building LLVM with
`-DLLVM_USE_SANITIZER=Address`:
```console
[2/2] Building GenVT.inc...
FAILED: include/llvm/CodeGen/GenVT.inc C:/Dev/llvm-project/Build_asan/include/llvm/CodeGen/GenVT.inc
cmd.exe /C "cd /D C:\Dev\llvm-project\Build_asan && C:\Dev\llvm-project\Build_asan\bin\llvm-min-tblgen.exe -gen-vt -I C:/Dev/llvm-project/llvm/include/llvm/CodeGen -IC:/Dev/llvm-project/Build_asan/include -IC:/Dev/llvm-project/llvm/include C:/Dev/llvm-project/llvm/include/llvm/CodeGen/ValueTypes.td --write-if-changed -o include/llvm/CodeGen/GenVT.inc -d include/llvm/CodeGen/GenVT.inc.d"       
=================================================================
==31944==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7ff6cff80d20 at pc 0x7ff6cfcc7378 bp 0x00e8...

Whenever linking with -nodefaultlibs for a MinGW target, we manually
need to specify a bunch of libraries - listed in ${MINGW_LIBRARIES}; the
same is already done for sanitizers and libunwind/libcxxabi/libcxx.

Practically speaking, linking with -nodefaultlibs but manually passing
the libraries in ${MINGW_LIBRARIES} restores most of the libraries that
are linked by default, except for the potential compiler builtins and
unwind library; i.e. it has essentially the same effect as linking with
"--unwindlib=none -rtlib=none", except that -rtlib doesn't accept such a
value.

When building only compiler-rt/lib/builtins, not all of compiler-rt,
${MINGW_LIBRARIES} is unset - set it manually here for that case. This
matches what is set in
compiler-rt/cmake/config-ix.cmake, except that the builtins (libgcc or
compiler-rt builtins) is omitted; the only use within lib/buitlins is
for the standalone libatomic, which explicitly already links against the
just-built builtins.

Fixes #74611

`llvm/test/CodeGen/RISCV/llvm.frexp.ll` and
`llvm/test/CodeGen/X86/llvm.frexp.ll` contain a number of disabled tests
for unimplemented functionality. This implements one missing part of it.

...that is causing the bug report when it's converted to the enum type.
This commit only improves the diagnostics and does not affect the set of
reports.

The implementation of these are modeled after the existing fastmath
flags for floating point arithmetic.