Only solve dest type is vector to avoid inverse transform in visitBitCast.

Reviewed By: spatel

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

The checker missed a check for parameter type of primary template of specialization template and this could cause build breakages.

Reviewed By: aaron.ballman, flx

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

Reviewed By: simoll

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

This pattern is what we get after DAG combine for C code like this.

short *ptr1, *ptr2, *ptr3;
unsigned diff = ptr1 - ptr2;
return ptr3[diff];

Reviewed By: reames

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

The tests here show the codegen for something like this C code.

unsigned diff = ptr1 - ptr2;
return ptr3[diff];

The pointer difference is truncated to 32-bits before being used
again as an index. In SelectionDAG this appears as an AND between
a SRL and a SHL. DAGCombiner will remove the shifts leaving only
an AND. The Mask now has 1,2, or 3 trailing zeros and 31, 30, or 29
leading zeros. We end up falling back to constant materialization
to create this mask.

We could instead use srli followed by slli.uw. Or since
we have an add, we can use srli followed by shXadd.uw.

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

This reverts the revert commit ad95255b.

The updated version also creates a load when the store may not execute.
In those cases, we still need to introduce a load in a function where
there may not have been one before, so this doesn't completely resolve
issue #51248.

Original message:

    When only a store is sunk, there is no need to create a load in the
    pre-header, as the result of the load will never get used.

    The dead load can can introduce UB, if the function is marked as
    writeonly.

    Reviewed By: nikic

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

If both a v2i32 DUP(x) and a v4i32 DUP(x) node exists, we can re-use the
larger node using a vector extract to obtain the smaller. This comes up
in the smull/smlal code, but needs a small fixup to allow the smull2
code in tryExtendDUPToExtractHigh/performAddSubLongCombine to still
match smull2 extracts.

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

Clang 3.7 and below is not actively used or supported in the test suite now, so
remove the workaround in the test.

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

znver1/2 models were incorrectly modelling the fpupipe (should be pipe2 for shift-by-scalar-amount and pipe1 for shift-by-element-amount) and znver1 ymm variants also require double pumping.

Now matches AMD SoG, Agner and instlatx64 numbers.

Thanks to @fabian-r for the report

Reviewed By: philnik, #libc

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

Both D121530 and D125606 had issues with this macro.

Reviewed By: #libc, philnik

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

This was a review suggestion from MaskRay that I forgot to incorporate
in the patch.

See: https://reviews.llvm.org/D124815

musl-libc doesn't support dladdr in statically linked binaries:

> Are you using static or dynamic linking? If static, dladdr is just a
> stub that always fails. It could be implemented to work under some
> conditions, but it would be highly dependent on what options you
> compile the binary with, since by default static binaries do not
> contain the bloat that would be needed to perform introspection.

Source: https://www.openwall.com/lists/musl/2013/01/15/25 (in response
to a bug report).

Libclang unfortunately uses dladdr to find the ResourcesPath so will
fail if it is linked statically on Alpine Linux. This patch fixes this
issue by falling back to getMainExecutable if dladdr returns an error.

Reference: https://github.com/llvm/llvm-project/issues/40641#issuecomment-981011427

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Reviewed By: JohnTitor

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

This fixes the broken Apple builds. This has been tested in D121530
(https://buildkite.com/llvm-project/libcxx-ci/builds/11113)

Before this patch, there was re-declaration error if error was encountered in
the same line. The recovery support acted only if this type of error was
encountered in the first line of the program and not in subsequent lines.

For example:

```
clang-repl> int i=9;
clang-repl> int j=9; err;
input_line_3:1:5: error: redefinition of 'j'
int j = 9;
```

Differential revision: https://reviews.llvm.org/D123674

8b4fa2c9 added this to remove left-over files on January.
Now we could assume they're cleaned up and this `rm` script is no longer necessary as FIXME states.

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

This patch adds support for applying a relation on domain/range of a relation.

Reviewed By: arjunp, ftynse

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

In LLVM's common loop terminology, an exit block is a block outside a
loop with a predecessor inside the loop. An exiting block is a block
inside the loop which branches to an exit block outside the loop.

This patch updates a few places where VPlan was using ExitBlock for a
block exiting a region. Those instances have been updated to use
ExitingBlock.

Reviewed By: Ayal

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

lldb will only backtrace a fixed number of stack frames, as a
last-ditch attempt to avoid a runaway looping backtrace.  It's
unusual that anyone ends up depending on this final safety net in
years. I picked the original number of 300000 was picked by seeing
how many stack frames I could make in a small recursive function
on Darwin systems before using the default stack space.  Checking
again today on a modern system, I can exceed this limit & lldb will
not show the original invocation of the recursing call.  Double the
old value to cover this larger maximum possible stack frame count,
as a default value.
(`target.process.thread.max-backtrace-depth`)

As an extension for REAL literals, we allow an exponent letter which
matches an explicit kind-param. The standard requires the exponent
to be 'E' if a kind-param is present. This patch
 - documents this extension in Extensions.md
 - enables a portability warning if it is used with -pedantic

The test case for this, kinds05.f90, needs D125804, which makes
test_errors.py test warnings as well, to actually test the warnings.
I include it already now to keep things together, it will do no harm
(I hope ...).

We also add WARNING-directives to the test kinds04.f90 in preparation
for D125804. As the exponent-letter 'Q' does not imply the same kind
on all platforms, the emitted warnings are platform-dependent.
Therefore, the test is duplicated into two variants which are run
conditionally.

Finally, we promote the portability warning for when the exponent letter
is neither 'E' nor matching the kind-param to a standard warning.

Reviewed By: klausler

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

There was a typo in the CMakeLists.txt for hmap tool that installed it to the wrong directory

https://github.com/llvm/llvm-project/issues/55753

Reviewed By: keith

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

When two or more generic interfaces are available by declaration or
by USE association at different scoping levels, we need to search
the outer generic interfaces as well as the inner ones, but only after
the inner ones have failed to produce a specific procedure that matches
a given set of actual arguments.  This means that it is possible for
a specific procedure of a generic interface of an inner scope to override
a conflicting specific procedure of a generic interface of an outer
scope.

Also cope with forward references to derived types when a generic
interface is also in scope.

Fixes LLVM bug https://github.com/llvm/llvm-project/issues/55240 and
LLVM bug https://github.com/llvm/llvm-project/issues/55300.

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

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

D102763 removed the almost support of `deplibs` but it seems `kw_deplibs` was missed.
This patch removes it.

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

When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, emit a portability warning rather than a fatal error if
the literal constant appears as the operand to a unary minus, since
the folded result will be in range.  And don't emit any warning if
the negated literal is coming from a module file -- f18 wrote the
module file and the warning would simply be confusing, especially to
the programmer that wrote (-2147483647_4-1) in the first place.

Further, emit portability warnings for the canonical expressions for
infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear
in a module file, for the same reason.  The Fortran language has no
syntax for these special values so we have to emit expressions that
fold to them.

Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and
https://github.com/llvm/llvm-project/issues/55081.

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

The `beginner` label is deprecated
and the `good first issue` label is now preferred.

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

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

For pointer variables, using getSymbolAddress cannot get the coorect
address for atomic read/write operands. Use genExprAddr to fix it.

Reviewed By: shraiysh, NimishMishra

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

The stop statement is allowed in OpenMP/OpenACC block region.

Reviewed By: kiranchandramohan, shraiysh

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

Reviewed By: ldionne, #libc

Spies: arichardson, smeenai, libcxx-commits, arphaman

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

Fixes llvm#53545

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

The convention is to use err_drv_unsupported_option_argument instead of adding a
new diagnostic for every option.

Update the diagnostic in D81404: the convention is to use
err_drv_unsupported_option_argument instead of adding a new diagnostic for every
option.

Reviewed By: nickdesaulniers

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