This should fix builders like
https://lab.llvm.org/buildbot/#/builders/139/builds/36522

This introduces R_RISCV_PLT32, a PC-relative data relocation that takes
the 32-bit relative offset to a function or its PLT entry.

This is needed to support relative vtables on RISCV.

Github PR: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/363

D143226 has the llvm parts.

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

Follow on to D144209 to support single implementation devirtualization
for Regular LTO when the vtable holds a function alias.

For now I have prevented other optimizations performed in regular LTO
that need to analyze the contents of the function target when the vtable
holds an alias, as I'm not sure they are always correct to perform in
that case.

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

Reviewed By: hctim

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

It's not pretty, but it makes the test run a lot faster.

Reviewed By: #libc, philnik

Spies: DavidSpickett, libcxx-commits

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

issue #60906

Reviewed By: serge-sans-paille

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

Remove mention of a variable that is not used in the example for checker:
cppcoreguidelines-avoid-non-const-global-variables

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

Passes in general shouldn't replace an alias with the aliasee (see
https://reviews.llvm.org/D66606). This can lead to situations where a
linkonce_odr symbol (which could be interposable if lowered to weak
linkage) can be replaced with a local aliasee which won't be
interposable. SVEC does this when the function is invoked by
FunctionPass Manager -> Loop Pass Manager -> Induction Variable Users in
the codegen pipeline. This was found in hwasan instrumented code where a
linonce_odr alias was replaced with its private aliasee.

This fixes the bug descriped at
https://github.com/llvm/llvm-project/issues/60668.

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

This revision is a part of a series of patches extending
AddressSanitizer C++ container overflow detection
capabilities by adding annotations, similar to those existing
in std::vector, to std::string and std::deque collections.
These changes allow ASan to detect cases when the instrumented
program accesses memory which is internally allocated by
the collection but is still not in-use (accesses before or
after the stored elements for std::deque, or between the size and
capacity bounds for std::string).

The motivation for the research and those changes was a bug,
found by Trail of Bits, in a real code where an out-of-bounds read
could happen as two strings were compared via a std::equals function
that took iter1_begin, iter1_end, iter2_begin iterators
(with a custom comparison function).
When object iter1 was longer than iter2, read out-of-bounds on iter2
could happen. Container sanitization would detect it.

In revision D132522, support for non-aligned memory buffers (sharing
first/last granule with other objects) was added, therefore the
check for standard allocator is not necessary anymore.
This patch removes the check in std::vector annotation member
function (__annotate_contiguous_container) to support
different allocators.

Additionally, this revision fixes unpoisoning in std::vector.
It guarantees that __alloc_traits::deallocate may access returned memory.
Originally suggested in D144155 revision.

If you have any questions, please email:
 - advenam.tacet@trailofbits.com
 - disconnect3d@trailofbits.com

Reviewed By: #libc, #sanitizers, philnik, vitalybuka

Spies: hans, EricWF, philnik, #sanitizers, libcxx-commits

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

It seems newer grpc / protobuf versions renamed
`Status::error_message()` and `Status::error_code()` to `message()` and
`code()` to prepare for replacement with `absl::Status` with the same
names.

As far as I can tell the new names are already available in the
grpc-1.36 version mentioned in the `README` file.

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

Summary:
Ever since the change to the new plugins the information messages are
common between the major plugins. This allows us to test the info.c file
generically.

Summary:
Internally we need to know the feature that was used to build the CUDA.
This used to be added when the deviceRTL was build via the OpenMP
interface, but ever since it was moved to call the packager explicitly
it was not being added. This causes failured if the user attempts to use
the library without LTO enabled.

It's possible for debugserver to attach to a process during the handoff
between /usr/lib/dyld and the dyld in the shared cache. When that
happens, we may end up in a state where there is no dyld in the process
and our debugging session is doomed. To make that scenario a lot less
likely, we can insert a sleep right before attaching after waiting to
find the right pid.

rdar://105513180

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

The sizes of input operands need being clampled only when there are
incomplete tiles, i.e., the padding value is set. The shape input slice
can be folded into constants when they are static shapes and tiling
sizes.

Reviewed By: chelini

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

The matching for V_FMA_MIX was partially implemented with a C++
matcher (for fmas with 32 bit results and 16 bit inputs) and partially
in tablegen (for fmas with 16 bit results). Move the C++ matcher logic
into tablegen to make this more consistent and so we can remove the
duplication between SDAG and GISel.

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

This reverts commit b3744233.

Causes regressions on some benchmarks.

Minor modifications to Diagnostic expectation to match the error generated in Mac.
Tested on M1 Mac.

Reviewed By: awarzynski

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

This gives our worker threads some names that allow easily identifying them in tools such as profilers and debuggers.

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

This reverts commit c7f9344d.

The GetRssFromBuffer scudo test case fails intermittently on Power, so this test
is disabled on the platform because of this.

Reviewed By: aartbik

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

On targets without ADDCARRY or ADDE, we need to emit a separate
SETCC to determine carry from the low half to the high half. Usually
we do (setult Lo, LHSLo). If RHSLo is 1 we can instead do (seteq Lo, 0).
This can reduce the live range of LHSLo.

This fix runtime problem due to generate this[:1] map info for non member
variable.
To fix this check VD, if VD is not null, it is not member from current
or base classes.

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

Incorrect API usage was detected by D144552.

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

On targets that lack ADDCARRY support we split a wide uaddo into
an ADD and a SETCC that both need to be split.

For (uaddo X, 1) we can observe that when the add overflows the result
will be 0. We can emit (seteq (or Lo, Hi), 0) to detect this.

This improves D142071.

There is an alternative here. We could use either ~(lo(X) & hi(X)) == 0 or
(lo(X) & hi(X)) == -1 before the addition. That would be closer to the
code before D142071.

Reviewed By: liaolucy

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

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

Allows us to handle expressions like -(a * b) + c

Based on the examples from D144366 that gcc seems to get.

Reviewed By: kpn

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

llvm::PointerIntPair has methods that when used together can invoke
undefined behavior by violating strict aliasing.

`getPointer()` uses the underlying storage as it's declared: `intptr_t`
`getAddrOfPointer()` casts the underlying storage as if it was a
`PointerTy`

This violates strict aliasing, so depending on how they are used, it's
possible to have the compiler to optimize the code in unwanted ways.
See the unit test in the patch. We declare a `PointerIntPair` and use
the `getAddrOfPointer` method to fill in the a pointer value.  Then,
when we use `getPointer` the compiler is thrown off, thinking that
`intptr_t` storage could not have possibly be changed, and the check
fails.

Reviewed By: efriedma

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

This enables conversion of OpenMP Target Data op with region from FIR Dialect to LLVM IR Dialect.

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

This case was being picked up by SVE code and printing an SVE
specific message.

This patch distinquishes RVV from SVE and provides a correct error
message for RVV.

The use of the generic isSizelessBuiltinType was also picking up
WebAssembly reference types which was probably an accident so I've
removed that.

I've named the test similar to SVE's test that contains this check.
Their test also tests the arm_sve_vector_bits attribute. I plan to
add something similar for RISC-V soon so I've adopted this naming.

Reviewed By: c-rhodes

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

This is only used by CodeGen. Moving it out of AMDGPUBaseInfo simplifies
future changes to make some of it depend on the subtarget.

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

The commit causes clang to crash. See https://reviews.llvm.org/D143840#4147234

This reverts commit 8498ba6c.

The runtime check was a too strong as the standard says.
> If it is polymorphic it shall not be an undefined pointer.
The check was checking if the pointer was associated.
Remove the check as other compilers do.

Depends on D144643

Reviewed By: PeteSteinfeld

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

When an element is extracted from a polymorphic array, it is
represented as a PolymorphicValue. The PolymorphicValue is
not a boxed value but holds the original polyrmophic array
and the element itself. This was raising an error in storage_size
lowering since we expect a boxed value to take advantage of
fir.box_elesize.
This patch handles PolymorphicValue correctly.

Reviewed By: PeteSteinfeld

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

Derived type `Destroy` function does not take step into consideration
when indexing the component element for deallocation. This leads to
incorrect deallocation in case like:

```
module mod1
  type :: t
    real, allocatable :: r(:)
  end type
contains
  subroutine do_smth(c)
    class(t), intent(out) :: c(:)
    do i = 1, size(c)
      if (allocated(c(i)%r)) then
        print*, i, 'not deallocated'
      end if
    end do
  end subroutine
end module

program test
  use mod1
  type(t) :: z(6)
  integer :: i
  do i = 1, 6
    Allocate(z(i)%r(i))
  end do
  call do_smth(z(::2))
end
```

Similar change was done in D142527

Reviewed By: klausler

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

This modifies it to work on both scalable and fixed vectors

Reviewed By: reames

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

Lower the two intrinsics introduced in D141924.

These intrinsics can be combined with loads and stores into the much more efficient segmented load and store instructions in a following patch.

Reviewed By: reames

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