Special casing the nonfinite exponent value everywhere is kind of
annoying.

Handle constant folding and idempotent folding. Not sure
this is an appropriate use of undef for the inf/nan case. The
C version says the second result is "unspecified". The AMDGPU
instruction returns 0.

Fixes regression reported after
0f4eb557

Identified another miscompile while working on fixing interleaving's
current miscompile in D154309. This is different from testcases landed in D154309,
since it showcases an incorrect sinking of store (the former testcases
in that review and follow-up ones) showed incorrect hoisting of loads
across stores.

Transformed if checks to asserts and simplified some more code to
improve compile time.

Linalg operations can include `complex` types in the src/target types.
This should include conversion between `arith` and `complex` types when
constructing `linalg` operations.

Reviewed By: kuhar

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

Instead of warning possibly up to 3 times about the same problem,
warn only about the actual missing directories.

This reverts commit 9b3323d3.

The warning will stay DefaultIgnore upstream, because a variety of
tests aren't expecting it and updating the tests isn't worth the
effort.

Before D150478, there were situations when Clang avoided parsing a module map because it was likely to re-define an already defined module (either by a PCM or by previously-found module map). Since Clang no longer performs that check and does parse the extra module map (due to the FW/FW_Private issue described in D150478), this patch re-implements the same semantics by skipping the duplicate definition of the framework module while parsing the module map.

Depends on D150478.

Reviewed By: benlangmuir

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

When Clang loads a PCM that depends on another PCM describing framework module "FW", `ModuleMap` registers "FW" as known, without seeing the module map that defines it (or the adjacent "FW_Private" module map). Later, when looking at a header from "FW_Private", `ModuleMap` returns early due to having knowledge about "FW" and never associates that header with "FW_Private", leading to it being treated as textual. This behavior is caused by D150292, where the scanner stops calling `HeaderSearch::lookupModule()` eagerly for every loaded PCM.

This patch skips an early check when trying to figure out the framework module for a header, which ensures the "FW" and (most importantly) "FW_Private" module maps can be parsed even after loading "FW" from a PCM. Note that the `HeaderSearch::loadModuleMapFile()` function we not call unconditionally has caching behavior of its own, meaning it will avoid parsing module map file repeatedly.

Depends on D150320.

Reviewed By: benlangmuir

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

Currently, `ASTReader` performs some checks to diagnose relocated modules. This can add quite a bit of overhead to the scanner: it requires looking up, parsing and resolving module maps for all transitively loaded module files (and all the module maps encountered in the search paths on the way). Most of those checks are not really useful in the scanner anyway, since it uses strict context hash and immutable filesystem, which prevent those scenarios in the first place.

This can speed up scanning by up to 30%.

Depends on D150292.

Reviewed By: benlangmuir

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

This is a prep patch for avoiding the quadratic number of calls to `HeaderSearch::lookupModule()` in `ASTReader` for each (transitively) loaded PCM file. (Specifically in the context of `clang-scan-deps`).

This patch explicitly serializes `Module::DefinitionLoc` so that we can stop relying on it being filled by the module map parser. This change also required change to the module map parser, where we used the absence of `DefinitionLoc` to determine whether a file came from a PCM file. We also need to make sure we consider the "containing" module map affecting when writing a PCM, so that it's not stripped during serialization, which ensures `DefinitionLoc` still ends up pointing to the correct offset. This is intended to be a NFC change.

Reviewed By: benlangmuir

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

When compiling in device only mode (e.g. --offload-device-only), the
host linker phase would not happen and therefore, the driver should
ignore all the host linker flags.

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

Change-Id: I8244acef5c33108cf15b1dbb188f974f30099718

Add test for simple scalar allocatable or pointer. Set up the TODO
to be triggered when the allocatable or pointer are arrays.
Support for pointer/allocatable arrays will come next.

Reviewed By: razvanlupusoru

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

Sometimes users pass this option when targeting embedded architectures like armv7m on non-darwin platforms.
This applies to watchOS and tvOS as well as iOS.

Depends on D155407

Reviewed By: MaskRay, ahatanak

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

This makes __threading_support contain nothing but the base threading
API provided by the system.

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

Lowering for reduction with dynamic shaped arrays is not implemented yet.
Add a proper TODO for the time being.

Reviewed By: razvanlupusoru

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

Fix some problems with INCLUDE line recognition pointed out by some
recently-added tests to the LLVM test suite.

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

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

Rename HIP_API_PER_THREAD_DEFAULT_STREAM and __HIP_NO_IMAGE_SUPPORT
so that they follow the convention with prefix and postfix __.

Reviewed by: Artem Belevich

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

It is not standard conforming under IMPLICIT NONE(TYPE) for a name to
appear in a DATA statement prior to its explicit type declaration,
but it is benign, supported in other compilers, and attested in real
applications.  Support it with an optional portability warning.

Fixes GitHub LLVM bug https://github.com/llvm/llvm-project/issues/63783.

Don't emit bogus compile-time error messages about out-of-range values
for the DIM= argument to LBOUND/BOUND when the array in question is an
assumed-rank dummy array argument.

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

The statement "A(J) = expr" could be an assignment to an element of an
array A, an assignment to the target of a pointer-valued function A, or
the definition of a new statement function in the local scope named A,
depending on whether it appears in (what might still be) the specification
part of a program or subprogram and what other declarations and definitions
for A might exist in the local scope or have been imported into it.

The standard requires that the name of a statement function appear in
an earlier type declaration statement if it is also the name of an
entity in the enclosing scope.  Some other Fortran compilers mistakenly
enforce that rule in the case of an assignment to the target of a
pointer-valued function in the containing scope, after misinterpreting
the assignment as a new local statement function definition.

This patch cleans up the handling of the various possibilities and
resolves what was a crash in the case of a statement function definition
whose name was the same as that of a procedure in the outer scope whose
result is *not* a pointer.

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

When the left-hand side of an assignment, or any other context demanding
definability, comprises a designator with a vector subscript that is
known at compilation time to have one or more duplicated elements,
emit an error message.

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

Entities declared with CLASS() must be dummy arguments, allocatables,
or pointers.  This constraint check is currently correct for objects
but not for procedures, and getting it right needs to avoid being
confused between pointers to procedures and pointers returned by
procedures.

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

The method cache stashes a mask in the high bits under some circumstances:
https://github.com/apple-oss-distributions/objc4/blob/689525d556eb3dee1ffb700423bccf5ecc501dbf/runtime/objc-cache.mm#L589

I'm hitting this now on macOS 13.4 arm64, so we can no longer rely on OBJC_FAST_IS_RW to identify potential pointers that need to be transformed

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

In the case where the expression was not yet associated with a storage location, we created a new storage location but failed to associate it with the expression.

The newly added test fails without the fix.

Reviewed By: xazax.hun

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

Since `StringRef::empty` can be used in constexpr context, it seems reasonable that `SMLoc::isValid` should be too.  The default-ctor and `operator==` are made constexpr for consistency.

In particular, the `constexpr` keyword is needed for silencing warnings on Windows (whereas Linux allows constexpr usage without the keyword).

Reviewed By: jpienaar

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

Rework the code used to check for calls to impure procedures in DO CONCURRENT
constructs.  The current code wasn't checking the representation of the
procedure references in the strongly typed expressions, so it was missing
calls to impure subprograms made via generic interfaces.  While here,
improve error messages, and fix some minor issues exposed by testing the
improved checks.

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

in getLastInstructionInBundle(), NFC.

Instead of building EntryToLastInstruction before the vectorization,
build it automatically during the calls to getLastInstructionInBundle()
function.

A BIND(C) interoperable procedure must have only interoperable dummy procedures.

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

At least one compiler more recent that the one that I test with emits
a warning (valid but benign) for some code in a unit test that I
modified a few minutes ago.  Adding some curly braces to placate the
compiler.

It was implicitly assumning that "/" would have no files in it, only
directories.  That's not true, for instance on macOS if you've navigated
to the root directory in the Finder...

Since we're assuming everything we check against is a directory, then we
need to filter the completion for that coming in.

The very first AA, at least the first one in order, is not necessary
anymore. `AAReturnedValues` was from a different time; one might say, a
simpler time.

It was rewriten once to use `Attribute::getAssumedSimplifiedValues`,
which is what the replacement, `AAPotentialValuesReturned`, does too.
To match the old behavior we needed to avoid the helper
`AAReturnedFromReturnedValues` and iterate the return instructions
explicitly, however, it is still less complexity than it was before.
`AAReturnedFromReturnedValues` and `getAssumedSimplifiedValues` now
allow users to stop at PHI and select nodes or to ignore those and look
through. `AANoFPClass` will stop at select and phi nodes to read the
fast math flags.

Fixes: https://github.com/llvm/llvm-project/issues/63404

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

This reverts commit ba9a7f73.

Bot failures due to enabling the warning by default.
e.g. https://lab.llvm.org/buildbot/#/builders/139/builds/45263

The Linalg vectoriser incorrectly recognises the following
`tensor.extract` as contiguous:
```
func.func @example(%in: tensor<123x321xf32>, %arg1: tensor<1x?x8xf32>) -> tensor<1x?x8xf32> {
  %c0 = arith.constant 1 : index
  %2 = linalg.generic {
    indexing_maps = [#map1],
    iterator_types = ["parallel", "parallel", "parallel"]
  } outs(%arg1 : tensor<1x?x8xf32>)
  {
  ^bb0(%arg3: f32):
    %idx_0 = linalg.index 0 : index
    %idx_1 = linalg.index 1 : index
    %idx = arith.addi %idx_0, %idx_1 : index
    %7 = tensor.extract %in[%c0, %idx] : tensor<123x321xf32>
    linalg.yield %7 : f32
  } -> tensor<1x?x8xf32>
  return %2 : tensor<1x?x8xf32>
}
```

However, the following index Op corresponds to the dynamic dimension
in the iteration space:
```
    %idx_1 = linalg.index 1 : index
```
The vectoriser should assume that:
  * this index Op _is not_ loop invariant,
  * the resulting memory access is a gather load
This is what this patch fixes.

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

The `see patch` tag conflicted w/ one later in the document. Changing
the text should fix the documentation build error.

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