Replace the custom libomp_check_linker_flag() implementation with
llvm_check_compiler_linker_flag() from the common cmake utils. Due
to the way the custom implementation is implemented (capturing
output from an entire nested cmake invocation) it can easily end
up incorrectly detecting flags as unavailable, e.g. because "error",
"unknown" or similar occurs inside compiler flags, the directory
name, etc.

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

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

This patch updates the vectorisation of the extract Op so that the
permutation map for the transfer_read Op is defined explicitly by the
vectoriser (as opposed to being constructed implicitly by the
transfer_read builder).

This change is needed for cases where the rank of the source tensor is
lower than the rank of the output vector generated by the vectoriser:
```mlir
    %17 = vector.transfer_read %arg1[%14, %16], %cst_4 {in_bounds = [true, true]} : tensor<257x24xf32>, vector<1x1x4xf32>
```
In cases like this, the vectorize will create the following permutation map:
```
  (d0, d1) -> (0, d0, d1)
```

In other cases the behaviour remains unchanged.

Fixes https://github.com/openxla/iree/issues/13036. That's also where
the test case was extracted from.

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

Fixes the following building errors, happening with official Android prebuilt clang 14 shipped with Android 13:

external/llvm-project/llvm/lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp:5491:13: error: no viable constructor or deduction guide for deduction of template arguments of 'tuple'
          ? std::tuple(HSAMD::V3::AssemblerDirectiveBegin,
            ^
...
external/llvm-project/llvm/lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp:5493:13: error: no viable constructor or deduction guide for deduction of template arguments of 'tuple'
          : std::tuple(HSAMD::AssemblerDirectiveBegin,
            ^

Fixes: 6443c0ee ("[AMDGPU] Stop using make_pair and make_tuple. NFC.")

Patch by Mauro Rossi!

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

Work group size attribute was set in Clang specific class. That's why
we cannot reuse this code in Flang.

If we move setting of this attribute to OpenMPIRBuilder, then we can reuse this
code in Flang and Clang. Function createOffloadEntry from OpenMPIRBuilder is
already used by Clang (via OpenMPIRBuilder::createOffloadEntriesAndInfoMetadata
function).

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

Reviewed By: jdoerfert

Revert "Fix handling of special and large vals in expand pattern for `round`" and "Add pattern that expands `math.roundeven` into `math.round` + arith"

This reverts commit 8d2bae9a and
commit ab2fc952.

Tests are broken on Mac M2

The pass uses ReachingDefAnalysis which has no information about
instructions in dead blocks.
So do not process them.

Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D148329

These tests have been failing on 32-bit machines.

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

This change fixes some static code analysis warnings.

Reviewed By: LuoYuanke

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

Currently we don't check call backs for global variable simplification.
What's more, the only way that we can register a simplification call back for
global variable is through its initializer (essentially a `Constant *`). It might
not correspond to the right global variable. In this patch, we set up a dedicated
simplification map for `GlobalVariable`.

Reviewed By: jdoerfert

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

/home/jiefu/llvm-project/lldb/source/Target/PathMappingList.cpp:51:5: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
    std::scoped_lock locks(m_mutex, rhs.m_mutex);
    ^
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
    class scoped_lock
          ^
/home/jiefu/llvm-project/lldb/source/Target/PathMappingList.cpp:72:3: error: 'scoped_lock' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
  std::scoped_lock locks(m_mutex, rhs.m_mutex);
  ^
/usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/mutex:692:11: note: add a deduction guide to suppress this warning
    class scoped_lock
          ^
2 errors generated.

This change fixes static code analysis errors

Reviewed By: LuoYuanke

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

This is a first step towards granularizing `<locale>`.

Reviewed By: ldionne, #libc

Spies: arichardson, libcxx-commits, mikhail.ramalho

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

This fix is similar to the one done in https://reviews.llvm.org/D148844.
This miss was caught by the risv64 builder.

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

We decided to go a different route. To make the switch easier, rip out the old integration first and build on a clean base.

Reviewed By: ldionne, #libc, #libc_abi

Spies: arichardson, libcxx-commits

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

I'd like to use this in a CI system where it's easier to tell the
program about paths than manipulate $PATH.

Close https://github.com/llvm/llvm-project/issues/62241

In tooling group (SG15), it is still unclear how tools should support
header units. Add a warning in the documentation to avoid further
confusions.

Fix wrong debug type.

Reviewed By: hanchung

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

This makes it easier to reuse the legality part for other import
policies that wouldn't use thresholds.

Importing un-inlinable functions is also legal, because they could be
further specialized in a context-specific way, without inlining.

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

Alan spotted another test failure that was a result of
https://reviews.llvm.org/D148546 when running expensive checks tests
locally on windows.

Reviewed By: ayzhao

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

Without this dependency, it is possible that llvm-lib.exe will not be
built, in which case CMake will try to use lib.exe to build libraries,
but this tool cannot handle bitcode files.

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

My reland of https://reviews.llvm.org/D148546 has caused a few windows
demangler tests to fail when run with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON
on windows.

I have a sneaking suspicion that MSVC's
std::string_view::iterator::operator* may be missing a nullptr check.

Link: https://lab.llvm.org/buildbot/#/builders/42/builds/9723/steps/7/logs/stdio

Reviewed By: ayzhao

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

This patch adds assertions to prevent the compilation when we try to
bit cast a type that is not trivially copyable when using
__builtin_bit_cast, or when we try to bit cast a type that is not
trivially copyable and trivially constructable when using memcpy.

Reviewed By: sivachandra

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

Summary:
The `+ptx` features correspond to the related CUDA version. We require a
certain set of features from the `ptxas` assembler, which is tied to the
CUDA version. Some of the ones set here were insufficient, so I am
simply setting a cutoff to the CUDA 9.0 release as the minimum. This
roughly corresponds to what should be required for sm_60 to be compiled
with the source.

Previously, `vecreduce_{and,or} vNi1` could lead to miscompilations because the legalizer first decides to `any_ext` the operand (which is correct for `vecreduce_{and,or}`) and then decides to use `vecreduce_u{min,max}` instead (for which `any_ext` is incorrect). This patch changes it so the `vecreduce_u{min,max}` operations use `sign_ext` instead of `any_ext`.

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

Reviewed By: craig.topper

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

Values in bounds are expected to have integer or index types. Enforce
this expectation by restricting the type to be IntOrIndex.

Reviewed By: razvanlupusoru

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

This bug was caught by the aarch64 full build builder.

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

In particular, make it `foo.a(foo.o)$ARCHIVE_OFFSET`. The goal is to
make it more similar to both ld64 implementation, which uses the
`foo.a(foo.o)$MODULE_ID` format. We dump some of these names in LTO
code, so matching ld64's format is helpful. This format is also more
similar to LLD-ELF's, which is `foo.a(foo.o at $ARCHIVE_OFFSET)`.

Reviewed By: #lld-macho, oontvoo

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

Reviewed By: aartbik

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

If the AVL is a virtual register defined by a vsetvli with the same
vlmax we need and the previous vsetvli we saw in the data flow also
has that vlmax, we can use the x0, x0 form when we insert a vsetvli.

Not only does this avoid an update of the VL physical register, but
it may allow doLocalPostpass to completely remove the inserted vsetvli
by rewriting the vtype of the previous vsetvli.

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

Allow two currently erroneous cases of !DIR$ IGNORE_TKR errors: allocatable
and pointers, and IGNORE_TKR(R) on (other) arguments passed via descriptors.
Downgrade these cases to warnings when they appear in external interfaces,
since their implementations may well be in C.  But retain the error status
on these cases for module procedures, since the Fortran implementation
probably can't work.

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

Currently conversions to interfaces may happen implicitly (e.g.
`Attribute -> TypedAttr`), failing a runtime assert if the interface
isn't actually implemented. This change marks the `Interface(ValueT)`
constructor as explicit so that a cast is required.

Where it was straightforward to I adjusted code to not require casts,
otherwise I just made them explicit.

Depends on D148491, D148492

Reviewed By: rriddle

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

This allows implicit conversion from `ElementsAttr` to `TypedAttr`, but
required renaming the `ElementsAttr::getType()` interface method to
`getShapedType`.

Reviewed By: rriddle

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

This adds `arith::ConstantOp::materialize`, which builds a constant from
an attribute and type only if it would result in a valid op. This is
useful for dialect `materializeConstant` hooks, and allows for removing
the previous `Attribute, Type` builder which was only used during
materialization.

Reviewed By: rriddle

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

instruction, NFC.

Reviewed By: aartbik

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

This is the first instance where we've really needed to add
documentation for a diagnostic group, but -Wwrite-strings really
deserves it.

This warning option changes the semantic behavior of code, so enabling
it can cause code to break (and disabling it can too). That's worth
calling out loudly in our documentation.

After the switch to `add_custom_target` to run integration tests, most
of them were not actually being run because of the difference in the way
the COMMAND value is treated between `add_custom_target` and
`add_custom_command`. This patch gets the integration tests to run
again by passing the correct set of arguments to `add_custom_target`.

Reviewed By: michaelrj

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