There are two ways of specifying a CPU on PowerPC:
power<N> and pwr<N>. Clang/LLVM traditionally
supports the latter and Clang replaces the former
with the latter when passing it to the back end for
the -mcpu= option. However, when the -mtune= option
was introduced, this replacement was not implemented for it.

This leaves us in an inconsistent state of accepting
both forms for -mcpu= and and only the latter for
-mtune=. Furthermore, it leaves us incompatible with
GCC which only understands the power<N> version for
both options.

This patch just adds the same handling for the long
names for -mtune= as already exists for -mcpu=.

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

VF, NFC.

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.

When the left-hand side of an allocatable assignment has an explicit character length,
rather than a deferred length that might imply reallocation, handle any discrepancy
in lengths via truncation or blank padding.

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

The compiler currently ignores attributes for PASS dummy arguments that
are incompatible between a type-bound procedure in an extended type and
the binding of the same name that it overrides in an ancestor type,
if any.  Strengthen this checking so that discrepancies between attributes
and intents are caught, and add some tests.

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

A generic procedure binding in an extended derived type may not have the
same name as a symbol inherited from an ancestor type unless that inherited
symbol is also a generic TBP.  Since generic names can be things like
"ASSIGNMENT(=)", name resolution doesn't use OkToAddComponent() for
generic TBPs, which would have caught this error as it does for other
symbols in derived types, so it must be special-cased.

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

The Fortran standard's various restrictions on the use of BIND(C)
often depend more on the presence or absence of an explicit NAME=
specification rather than on its value, but semantics and module
file generation aren't making distinctions between explicit NAME=
specifications that happen to match the default name and declarations
that don't have NAME=.  Tweak semantics and module file generation
to conform, and also complain when named BIND(C) attributes are
erroneously applied to entities that can't support them, like
ABSTRACT interfaces.

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

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.