Fortran doesn't allow a BIND(C) variable or a component of a BIND(C)
type to be an array with no elements.

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

When a procedure binding in a derived type has PRIVATE accessibility,
it may not be an override of a type-bound procedure that is accessible.

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

Generic interfaces are not permitted to have intrinsic procedures or
statement functions as specific procedures.

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

Provide the name of the construct and the clause info (reduction)
in the TODO mesage.

Reviewed By: DavidTruby

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

A procedure defined in an ABSTRACT INTERFACE may not appear as
a specific procedure in a generic interface.

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

The Fortran 2018 standard, perhaps as an attempt to prevent ambiguity
in  older compilers, requires that a statement function appear in an
explicit type declaration statement if its name is also accessible
from a host scope.  F18 processes the specification parts of inner
procedures first, so we don't need this requirement to prevent
ambiguity, and can only really check it retrospectively after name
resolution.  Emit a portability warning when appropriate.

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

This had been removed as part of 3a0f88c4. It turns out that this
did break some code, but we never noticed because it requires including
<stdint.h> (and nothing else), and then using one of the types from
that header. It also requires running with modules enabled in a Standard
no later than C++17.

After the test refactorings in D145116, this bug would be caught
by running a CI job on macOS with modules enabled in C++17 mode
(but surprisingly not with more recent standards). This patch doesn't
add such a job because it is deemed a corner case.

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

Whenever, possible, use ASSERT_SAME_TYPE instead of static_assert along
with std::is_same in the depr header tests. This prevents dragging in
multiple headers unrelated to the header being tested, which can (and
has) hidden issues.

Also, add a couple of tests to ensure that basic declarations in
<stddef.h> and <stdint.h> are available when including just those
headers, since the rest of the tests for those types require pulling
in additional dependencies.

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

This case has already been handled by D106449.

The test for compatible function results needs to be nearly strict
equality of their types, not the usual actual/dummy type compatibility
test used in other situations.  The exceptional case is that assumed
length CHARACTER function results are compatible with explicit length
results of the same kind.  In particular, a function returning a
polymorphic pointer is not compatible with a function returning a
monomorphic pointer even of the same declared type.

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

The code that visits all pairs of constant SHIFT= and SIZE= arguments
in an array-valued call to the ISHFTC intrinsic function had a bad loop
test that affected the case where one of these arguments was scalar and
the other was not.  Fix it, and add tests.

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

The actual argument associated with a dummy argument with the TARGET attribute is
not required to be itself a target or pointer, or even to be a variable, but in
those cases, any pointer that is associated with the dummy argument during the
execution of the procedure is either going to be invalid afterwards because it
points to temporary storage that has since been deallocated or an optimization
time bomb because it aliases an object that isn't a target.  Add warnings for
these cases.

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

Reviewed By: lntue

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

Incorrect API usage was detected by D144552.

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

since it depends on CFG.

Otherwise some passes will try to merge them and cause
incorrect results.

Reviewed by: Artem Belevich

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

The issue seems to be caused by the definition of `SafeIntIterator` and
is otherwise unrelated to the implementation of `append_range`.

We have a simialr test below, so this does not meaningfully decrease the
test coverage of `append_range`.

See the discussion in: https://reviews.llvm.org/D144420#4164373

Issue: https://github.com/llvm/llvm-project/issues/61122

More coverage for D145073.

Add an optional error check to test case for it to pass on targets that do not support thread_local storage.

Reviewed By: aaron.ballman, abhina.sreeskantharajan

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

Pointer bitcasts no longer occur with opaque pointers -- and in
this case not handling them allows us to drop the code for
promoting constant expressions to instructions as well.

rdar://104059106

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

And drop the unnecessary main function.

This is a mechanical prep change for scalable vector support.  All it does is move the point of TypeSize to unsigned (i.e. the unsafe cast) closer to point of use.

This is guarding a check for isTypeLegal so it should check is
LegalTypes.

Fixes PR61111.

Reviewed By: RKSimon

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

This Patch gives ExtractAPI the ability to emit correct availability information for symbols marked as unavailable on a specific platform ( PR#60954 )

Reviewed By: dang

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

Incorrect API usage was detected by D144552.

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

Incorrect API usage was detected by D144552.

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

...rather than on potentially just a declaration.

Without the fix, the newly added clang/test/SemaCXX/warn-undefined-internal.cpp
failed with

> error: 'warning' diagnostics expected but not seen:
>   File /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp Line 12 (directive at /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp:13): function 'test2()::S::f' has internal linkage but is not defined
> error: 'note' diagnostics expected but not seen:
>   File /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp Line 14 (directive at /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp:15): used here

(I ran into this when two LibreOffice Clang plugins produced false positive
warnings, as they relied on Decl::isReferenced() returning true for such virtual
member functions of local classes.)

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

This reverts commit 4e7d40e0.

Relanding after fixing Polly related build error.

This reverts commit 7b26dcae.

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

Incorrect API usage was detected by D144552.

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

This patch involves boolean ring to simplify logical operations. We can treat `&` as ring multiplication and `^` as ring addition.
So we need to canonicalize all other operations to `*` `+`. Like:
```
a & b -> a * b
a ^ b -> a + b
~a -> a + 1
a | b -> a * b + a + b
c ? a : b -> c * a + (c + 1) * b
```
In the code, we use a mask set to represent an expression. Every value that is not comes from logical operations could be a bit in the mask.
The mask itself is a multiplication chain. The mask set is an addiction chain.
We can calculate two expressions based on boolean algebras.

For now, the initial patch only enabled on and/or/xor,  Later we can enhance the code step by step.

Reference: https://en.wikipedia.org/wiki/Boolean_ring

Reviewed By: spatel

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

This is an oversight, where we normalized the path, but we didn't use it
in the filtering.

Add tests for more complicated scratch load and store patterns.
Includes:
- sign and zero extending loads of i8 and i16 to i32 into 32-bit register
- D16 instructions that affect only high or low 16 bits of 32-bit register
 - D16 sign and zero extending loads of i8 to i16 into high or low 16 bits
   of 32-bit register
 - D16 loads of i16 to high or low 16 bits of 32-bit register
 - D16 stores of i8 and i16 from high 16 bits of 32-bit register

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

This patch adds AArch64 CodeGen support such that the type can be passed
and returned to/from functions, and also adds support to use this type in
load/store operations and PHI nodes.

Reviewed By: paulwalker-arm

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

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