We can now target the NVPTX architecture directly via
`--target=nvptx64-nvidia-cuda`. This currently does not define the
`__CUDA_ARCH__` macro with is used to allow code to target different
codes based on support. This patch simply adds this support.

Reviewed By: tra, jdoerfert

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

If we have a `%typemap(freearg)` that frees the argument, we shouldn't
free it manually on an error path before calling `SWIG_fail`.
`SWIG_fail` will already free the memory in this case, and doing it
manually results in a double free.

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

Constraint checking for explicit SAVE attributes is more
accurate when done along with other declaration checking, rather
than on the fly during name resolution.  This allows us to
catch attempts to attach explicit SAVE attributes to anything
that can't have one (constraints C859, C860).

Also delete `IsSave()`, whose few remaining uses were changed to the
more general `IsSaved()` predicate that seems more correct for
those uses, returning true for both explicit and implied SAVE
attributes.

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

A PRIVATE procedure binding in a derived type extension may not
be an override of a PUBLIC procedure binding.  Declaration checking
for this case was working only in the presence of an explicit
PUBLIC accessibility attribute, when it should be checking for the
absence of a PRIVATE accessibility attribute.

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

Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current check misinterprets the constraint as applying only to
explicitly INTRINSIC or NON_INTRINSIC module natures.

Change the check to also apply to non-explicit module natures, and
also downgrade it to a portability warning, since there is no ambiguity
and I suspect that we need to accept this usage when building f18's
own intrinsic modules.

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

This implements the fake return after a successful longjmp(), as
described in the linux man page:

Following  a  successful  longjmp(), execution continues as if setjmp()
had returned for a second time.  This  "fake"  return  can  be  distin-
guished from a true setjmp() call because the "fake" return returns the
value provided in val.  If the programmer mistakenly passes the value 0
in val, the "fake" return will instead return 1.

Reviewed By: sivachandra

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

GDB 11.2 generates V8 version of gdb-index where it de-duplicates entries in
constant pool based on cu indices. Changed how constant pool entries are counted
to account for this.

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

A positional (non-keyword) actual argument or alternate return label is not
allowed to follow an actual argument with a keyword.

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

When multiple scopes in a compilation define interfaces (explicit
or implicit) for an external procedure, warn when those interfaces
are inconsistent.

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

Complain about the ASYNCHRONOUS attribute on symbols that aren't
variables.

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

Reviewed By: eric-k256

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

Procedures with the EXTERNAL attribute (explicit or implied) are
not permitted to be ALLOCATABLE or be arrays if their interfaces
are implicit.

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

Polynomial approximations assume F32 values. We can convert all non-f32
cases to operate on f32s with intermediate casts.

Reviewed By: jpienaar

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

The present I/O infrastructure for user-defined derived type I/O
subroutines works fine for type-bound I/O generic bindings.  It also works
for explicit INTERFACE blocks and GENERIC statements that define
UDDIO subroutines in the same scope as the definition of the derived type,
so long as the specific procedures in those bindings are module procedures
or external procedures.

For non-type-bound UDDTIO specific procedures that are dummy procedures,
thunks of inner procedures, or procedure pointers, or that are defined with
interfaces or GENERIC outside the scope of the definition of the derived
type, a new runtime I/O API is needed so that lowering can generate
a call that supplies the appropriate procedure as well as the defined
type instance.

This patch specifies and implements this new runtime API and provides
utility routines for lowering to use to determine whether it should be
called for any particular OutputItem or InputI...

Coverity static analysis tool found PolicyBitMask being used
uninitialized in push_back call in RVVEmitter::createRVVIntrinsics()
but this variable has no uses.

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

Related to a02c3af9. Fixes #61700.

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

Of my contact email. Sorry for the churn.

As well as updating .mailmap

There are only two cases here. Using an assert ensures there is
no handled third case.

Also move comment to avoid odd formatting.

Reviewed By: reames

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

This reverts commit ee232506.
As discussed in https://reviews.llvm.org/D146668 we'll find another way
forward.

This reverts commit 0c5cee77.
As discussed in https://reviews.llvm.org/D146668 we'll find another way
forward.

Specifically, we support this:

  ld64.lld -dylib foo.o libbar.dylib -exported_symbol _bar -o libfoo.dylib

Where `_bar` is defined in libbar.dylib.

Reviewed By: #lld-macho, smeenai

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

As discussed in https://reviews.llvm.org/D146668 I will be reverting
0c5cee77 and ee232506.
I'm removing NO_PLUGIN_DEPENDENCIES from lldbTarget first so that these
reverts will not leave LLDB in a bad state afterwards.

Even for experimental extensions, I think we always include "Std"
in the feature name.

Reviewed By: asb

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

Added semantics tests for aspects of CHANGE TEAM statements which are not duplicates from FORM TEAM statements.

Reviewed By: ktras

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

I think the failure was caused by a mistake in an earlier patch.

Original commit message:

We've supported .insn for non-compressed for a while. This finishes the compressed supported.

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

Lowering i1 (inreg) sext with `(NEG (AND %val, 1))`.

The gather scatter lowering pass can fold multiplies of a step vector
into the stride for the recursive case, so this extends it for the
non-recursive case.
The logic can probably be shared between the two at some point to extend
it to shls and ors.

Reviewed By: reames

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

Reviewed By: craig.topper

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

Tested locally with `bazel build --repo_env=CC=clang --repo_env=BAZEL_CXXOPTS="-std=c++17" @llvm-project//mlir:mlir-opt`.

Reviewed By: jyknight

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

Given:
```
struct x y;
int main(void)
{
    (void)(1 ? y : y);
}
struct x {int i;};
```
The conditional operator(?:) requires the second and third operands to
be of compatible types. To be compatible, they also need to be
complete (however, both can be void). Therefore, the expected response
from clang after running the above code as a C program should be error
dialogue pointing out that both the types are incomplete hence
incompatible, but the code compiled without any errors.

The patch ensures the completeness in the CheckCondtionalOperand
function present in llvm-project/clang/lib/Sema/SemaChecking.cpp.

Fixes https://github.com/llvm/llvm-project/issues/59718
Differential Revision: https://reviews.llvm.org/D144358

Currently the GPU build requires the `LLVM_LIBC_FULL_BUILD` option to be
set. This patch changes the logic so that it is always enabled when
targeting the GPU. Also, this patch allows `LIBC_GPU_BUILD` and
`LIBC_GPU_ARCHITECTURES` to both enable a GPU build. Now, enabling the
GPU support should only require the following CMake:

```
  -DLLVM_ENABLE_RUNTIMES=libc -DLIBC_GPU_ARCHITECTURES=gfx1030
```

Reviewed By: jdoerfert, sivachandra

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

The 2>&1 moving part is similar to commit 731264b0.

Original commit message:
I recently added a check to make sure the lower 2 bits of the opcode
were 0x3. A post commit comment pointed out this would be allowed
for a custom extension when C is not supported.

Note, binutils does have this restriction.