On AIX, char bitfields have the same alignment as unsigned int.
Reference: https://reviews.llvm.org/D87029

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

[clang] Invalidate a non-dependent-type RecordDecl when it has any dependent-type base class specifier.

This happens during the error-recovery, and it would esacpe all
dependent-type check guards in getTypeInfo/constexpr-evaluator code
paths, which lead to crashes.

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

Strictly speaking, the architecture manual no longer uses the st
mnemonic, but that's a much more intrusive change for little gain.

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

This adds the straightforward conversion for EqualOp
(two complex numbers are equal if both the real and the imaginary part are equal).

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

When trying to return a type such as <vscale x 1 x i32> from a
function we crash in DAGTypeLegalizer::WidenVecRes_EXTRACT_SUBVECTOR
when attempting to get the fixed number of elements in the vector.

For the simple case we are dealing with, i.e. extracting
<vscale x 1 x i32> from index 0 of input vector <vscale x 4 x i32>
we can simply rely upon existing code that just returns the input.

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

Haswell, Excavator and early Ryzen all have slower 256-bit non-uniform vector shifts (confirmed on AMDSoG/Agner/instlatx64 and llvm models) - so bump the worst case costs accordingly.

Noticed while investigating PR50364

This adds custom lowering for the MLOAD and MSTORE ISD nodes when
passed fixed length vectors in SVE. This is done by converting the
vectors to VLA vectors and using the VLA code generation.

Fixed length extending loads and truncating stores currently produce
correct code, but do not use the built in extend/truncate in the
load and store instructions. This will be fixed in a future patch.

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

This reverts commit 76b8754d and ensures the PCM files are created in the correct directory (not in the current working directory).

This will allow to use llvm-strip with file names that begin with dashes.

Reviewed By: jhenderson

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

This adds some extra codegen tests for abs and hadd, regenerating some
of the existing tests with updated check lines.

This patch prepares llvm-objcopy to move its implementation
into a separate library. To make it possible it is necessary
to minimize internal dependencies.

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

The Linux kernel has removed the interface to cyclades from
the latest kernel headers[1] due to them being orphaned for the
past 13 years.

libsanitizer uses this header when compiling against glibc, but
glibcs itself doesn't seem to have any references to cyclades.

Further more it seems that the driver is broken in the kernel and
the firmware doesn't seem to be available anymore.

As such since this is breaking the build of libsanitizer (and so the
GCC bootstrap[2]) I propose to remove this.

[1] https://lkml.org/lkml/2021/3/2/153
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379

Reviewed By: eugenis

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

This will make it easier to track address offsets in folded loads/broadcasts of subvectors

Check if it is legal to vectorize reduction.

Reviewed By: frasercrmck

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

When attempting to return something like a <vscale x 1 x i32>
type from a function we end up trying to widen the vector by
inserting a <vscale x 1 x i32> subvector into an undefined
<vscale x 4 x i32> vector. However, during legalisation we
then attempt to widen the INSERT_SUBVECTOR operands and hit
an error in WidenVectorOperand.

This patch adds a new WidenVecOp_INSERT_SUBVECTOR function
that currently only supports inserting subvectors into undefined
vectors.

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

Instead, use createOrFold builders which result in more static information available.

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

Also add a minimal test case for vector.print.

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

We have been handling filters and landingpads incorrectly all along. We
pass clauses' (catches') types to `__cxa_find_matching_catch` in JS glue
code, which returns the thrown pointer and sets the selector using
`setTempRet0()`.

We apparently have been doing the same for filters' (exception specs')
types; we pass them to `__cxa_find_matching_catch` just the same way as
clauses. And `__cxa_find_matching_catch` treats all given types as
clauses. So it is a little surprising; maybe we intended to do something
from the JS side and didn't end up doing?

So anyway, I don't think supporting exception specs in Emscripten EH is
a priority, but this can actually cause incorrect results for normal
catches when functions are inlined and the inlined spec type has a
parent-child relationship with the catch's type.

---

The below is an example of a bug that can happen when inlining and class
hierarchy is mixed. If you are busy you can skip this part:
```
struct A {};
struct B : A {};

void bar() throw (B) { throw B(); }

void foo() {
  try {
    bar();
  } catch (A &) {
    fputs ("Expected result\n", stdout);
  }
}
```

In the unoptimized code, `bar`'s landingpad will have a filter for `B`
and `foo`'s landingpad will have a clause for `A`. But when `bar` is
inlined into `foo`, `foo`'s landingpad has both a filter for `B` and a
clause for `A`, and it passes the both types to
`__cxa_find_matching_catch`:
```
__cxa_find_matching_catch(typeinfo for B, typeinfo for A)
```
`__cxa_find_matching_catch` thinks both are clauses, and looks at the
first type `B`, which belongs to a filter. And the thrown type is `B`,
so it thinks the first type `B` is caught. But this makes it return an
incorrect selector, because it is supposed to catch the exception using
the second type `A`, which is a parent of `B`. As a result, the `foo` in
the example program above does not print "Expected result" but just
throws the exception to the caller. (This wouldn't have happened if `A`
and `B` are completely disjoint types, such as `float` and `int`)

Fixes https://bugs.llvm.org/show_bug.cgi?id=50357.

Reviewed By: dschuff, kripken

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

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

llvm::Any::TypeId::Id relies on the uniqueness of the address of a static
variable defined in a template function. hidden visibility implies vague linkage
for that variable, which does not guarantee the uniqueness of the address across
a binary and a shared library. This totally breaks the implementation of
llvm::Any.

Ideally, setting visibility to llvm::Any::TypeId::Id should be enough,
unfortunately this doesn't work as expected and we lack time (before 12.0.1
release) to understand why setting the visibility to llvm::Any does work.

See https://gcc.gnu.org/wiki/Visibility and
https://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html
for more information on that topic.

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

bswap.v2i16 + sitofp in LLVM IR generate a sequence of:

  - REV32 + USHR for bswap.v2i16
  - SHL + SSHR + SCVTF for sext to v2i32 and scvt

The shift instructions are excessive as noted in PR24820, and they can
be optimized to just SSHR.

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

Stack allocate at most two ScalarAssign elements. Using the default number of inlined elements triggered a static assert in some setups (https://reviews.llvm.org/D102075).

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

getSourceText could return an empty string for error cases (e.g. invalid
source locaiton), this patch makes the code more robust.

The crash did happen in our internal codebase, but unfortunately I
didn't manage to get a reproduce case. One thing I can confirm from
the core dump is that the crash is caused by calling isRawStringLiteral
on an empty Text.

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

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

sleep(1) does not guaranty afterfork order.
Also relative child/parent afterfork order is not important for this test so we
can just avoid checking that.

Reviewed By: dvyukov

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

This reverts commit 81c18ce0.

That fixes a problem of using bundler with file names starting with dash.

Reviewed By: ABataev

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

In LAM model X86_64 will use bits 57-62 (of 0-63) as HWASAN tag.
So here we make sure the tag shift position and tag mask is correct for x86-64.

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

Reviewed By: hubert.reinterpretcast

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

If a test does not contain an " simd" but -fopenmp-simd RUN lines we can
just check that we do not create __kmpc|__tgt calls.

Reviewed By: ABataev

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

Currently 1 byte global object has a ridiculous 63 bytes redzone.
This patch reduces the redzone size to be less than 32 if the size of global object is less than or equal to half of 32 (the minimal size of redzone).
A 12 bytes object has a 20 bytes redzone, a 20 bytes object has a 44 bytes redzone.

Reviewed By: MaskRay, #sanitizers, vitalybuka

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