Test failed on ppc
(https://lab.llvm.org/buildbot/#/builders/231/builds/18902), and logs
shows missed import.

Cannot reproduce this with machines I could access so far.
https://gcc.gnu.org/wiki/CompileFarm seems to provide ppc64 machine.
Mark the thinlto icp test as unsupported for now.

reading dylibs

* This is a better fix than what I originally did to appease CI.

This implements a post-commit suggestion for #75679.

…e introduced by oneAPI DPC++ compiler 2024.0

Looks like adding attributes to lambdas wasn't added to ISO C++ until
C++23.
Forget lambdas and just use a static function.

In the change that added `--gap-fill`, the condition to choose the
sections to write in `BinaryWriter::write()` did not exclude zero-size
sections. However, zero-size sections did not have correct offsets
assigned in `BinaryWriter::finalize()`. The result is either a failed
assertion, or memory corruption due to writing to the buffer beyond its
size.
To fix this, exclude zero-size sections from writing. Also, add a zero-size
section to the test, which would trigger the problem.

https://github.com/llvm/llvm-project/pull/75635#issuecomment-1863433937

```
/b/s/w/ir/x/w/llvm_build/./bin/clang --target=aarch64-unknown-linux-gnu --sysroot=/b/s/w/ir/x/w/cipd/linux -DHAS_ASM_LSE -DVISIBILITY_HIDDEN  --target=aarch64-unknown-linux-gnu -O2 -g -DNDEBUG -fno-lto -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -DCOMPILER_RT_HAS_FLOAT16 -MD -MT CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model/aarch64.c.o -MF CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model/aarch64.c.o.d -o CMakeFiles/clang_rt.builtins-aarch64.dir/cpu_model/aarch64.c.o -c /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/builtins/cpu_model/aarch64.c
In file included from /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/builtins/cpu_model/aarch64.c:43:
/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/builtins/cpu_model/aarch64/lse_atomics/sysauxv.inc:5:41: error: use of undeclared identifier 'HWCAP_ATOMICS'
    5 |   __aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
      |                                         ^
1 error generated.
```

This is breaking Android compiler-rt builds.

This patch fixes:

  clang/lib/Interpreter/CodeCompletion.cpp:126:35: error: 'startswith'
  is deprecated: Use starts_with instead
  [-Werror,-Wdeprecated-declarations]

  clang/lib/Interpreter/CodeCompletion.cpp:189:42: error: 'startswith'
  is deprecated: Use starts_with instead
  [-Werror,-Wdeprecated-declarations]

This patch fixes:

  third-party/unittest/googletest/include/gtest/gtest.h:1379:11:
  error: comparison of integers of different signs: 'const int' and
  'const unsigned int' [-Werror,-Wsign-compare]

  llvm/unittests/Support/CommandLineTest.cpp:2294:3: note: in
  instantiation of function template specialization
  'testing::internal::EqHelper::Compare<int, unsigned int, nullptr>'
  requested here

This patch contains changes from
002d471a, in
addition to a bug fix that added a virtual destructor to
`CompletionContextHandler`

The original changes in the orginal commit piggybacks on clang's
semantic modules to enable semantic completion.  In particular, we use
`CodeCompletionContext` to differentiate two types of code completion.
We also
extract the relevant type information from it.

Otherwise for ASAN configured runs of the test, the test will fail due
to the
sanitizer rather than via SIGABRT.

Summary:
A recent patch allowed us to easily replace GNU atomics with scoped
variants that make use of the backend's handling for more permissive
scopes. The default is full "system" scope, that means the atomic
operation must be consistent with operations that may happen on the
host's memory. This is generally only required for processes that are
communicating with something via global fine-grained memory. This patch
uses these atomics to make everything device scoped, as nothing in the
OpenMP runtime should depend on the host.

This is only provided as a very new clang extension but the DeviceRTL is
only compiled with clang so it is always available.

Reland the reland "[PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon as delimiter for local-linkage varibles. "   (#75954)

Simplify the compiler-rt test to make it more general for different
platforms, and use `*DAG` matchers for lines that may be emitted
out-of-order.
- The compiler-rt test passed on a Windows machine. Previously name
matchers don't work for MSVC mangling
(https://lab.llvm.org/buildbot/#/builders/127/builds/59907)
- `*DAG` matchers fixed the error in
https://lab.llvm.org/buildbot/#/builders/94/builds/17924

This is the second reland and fixed errors caught in first reland
(https://github.com/llvm/llvm-project/pull/75860)

**Original commit message**
Commit fe051934 (phab D156569), IRPGO names uses format
`[<filepath>;]<linkage-name>` while prior format is
`[<filepath>:<mangled-name>`. The format change would break the use case
demonstrated in (updated)
`llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` and
`compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp`

This patch changes `GlobalValues::getGlobalIdentifer` to use the
semicolon.

To elaborate on the scenario how things break without this PR
1. IRPGO raw profiles stores (compressed) IRPGO names of functions in
one section, and per-function profile data in another section. The
[NameRef](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/compiler-rt/include/profile/InstrProfData.inc#L72)
field in per-function profile data is the MD5 hash of IRPGO names.
2. When raw profiles are converted to indexed format profiles, the
profiled address is
[mapped](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/ProfileData/InstrProf.cpp#L876-L885)
to the MD5 hash of the callee.
3. In `pgo-instr-use` thin-lto prelink pipeline, MD5 hash of IRPGO names
will be
[annotated](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L1707)
as value profiles, and used to import indirect-call-prom candidates. If
the annotated MD5 hash is computed from the new format while import uses
the prior format, the callee cannot be imported.

*
`compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp`
is added to have an end-to-end test.
* `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll`
is updated to have better test coverage from another aspect (as runtime
tests are more sensitive to the environment and may be skipped by some
contributors)

Use a size smaller than the smallest supported page size so that we
don't
clobber over any guard pages, which may result in a segfault before
__stack_chk_fail can be called.

Also, move __stack_chk_fail outside of our namespace.

The patch introduces a `SubCommandGroup` class which represents a list
of subcommands. An option can be added to all these subcommands using
one `cl::sub(group)` command. This simplifies the declaration of options
that are shared across multiple subcommands of a tool.

Make the `--implicit-check-not` account for the file extension as well.
This will still fail if we ever have a builder with `.dylib` in its
name, and we probably want a more robust solution, but this addresses
the immediate issue.

Fixes https://github.com/llvm/llvm-project/issues/75850
Fixes https://github.com/llvm/llvm-project/issues/75910

The patch adds a helper method to iterate over all subcommands to which
an option belongs. Duplicate code is removed and replaced with calls to
this new method.

__stack_chk_fail should be provided by libc.a, not startup files.

Add __stack_chk_fail to existing linux and arm entrypoints. On Windows
(when
not targeting MinGW), it seems that the corresponding function
identifier is
__security_check_cookie, so no entrypoint is added for Windows.
Baremetal
targets also ought to be compileable with `-fstack-protector*`

There is no common header for this prototype, since calls to
__stack_chk_fail
are meant to be inserted by the compiler upon function return when
compiled
`-fstack-protector*`.

Adds emitting the exception table and the EH registers for XPLINK.

---------

Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>

We included these in the commit message when we added
`-ffat-lto-objects`, but they should be in the documentation as well.

Finishes implementation of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be synchronized
with the underlying stream?

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

ompt/synchronization/[masked.c | master.c] tests fail due to a wrong
offset being calculated for the possible return addreses. PR #65936
fixes this for Darwin and the same has to be done for Linux.

Updates #69627

This is a re-land of https://github.com/llvm/llvm-project/pull/73685

Reviewers: petrhosek, DavidSpickett

Pull Request: https://github.com/llvm/llvm-project/pull/75635

This reverts commit 025d048b.

It broke one of the sanitizer bots:

https://lab.llvm.org/buildbot/#/builders/240/builds/20666

This reverts commit 17aa5201.

This is a re-land of https://github.com/llvm/llvm-project/pull/73685

Reviewers: petrhosek, DavidSpickett

Pull Request: https://github.com/llvm/llvm-project/pull/75635

This patch fixes a crash caused when the transform library interpreter
is given an IR that fails to parse.

It is a trivial early-return case. If the cloned ops are not returned,
it will generate `extract_slice` op that extracts the whole slice.
However, it is not folded away. Early-return to avoid the case.

E.g.,

```mlir
func.func @matmul_tensors(
  %arg0: tensor<?x?xf32>, %arg1: tensor<?x?xf32>, %arg2: tensor<?x?xf32>)
    -> tensor<?x?xf32> {
  %0 = linalg.matmul  ins(%arg0, %arg1: tensor<?x?xf32>, tensor<?x?xf32>)
                     outs(%arg2: tensor<?x?xf32>)
    -> tensor<?x?xf32>
  return %0 : tensor<?x?xf32>
}

module attributes {transform.with_named_sequence} {
  transform.named_sequence @__transform_main(%arg1: !transform.any_op {transform.readonly}) {
    %0 = transform.structured.match ops{["linalg.matmul"]} in %arg1 : (!transform.any_op) -> !transform.any_op
    %1 = transform.structured.tile_using_for %0 [0, 0, 0] : (!transform.any_op) -> (!transform.any_op)
    transform.yield
  }
}
```

Apply the transforms and canonicalize the IR:

```
mlir-opt --transform-interpreter -canonicalize input.mlir
```

we will get

```mlir
module {
  func.func @matmul_tensors(%arg0: tensor<?x?xf32>, %arg1: tensor<?x?xf32>, %arg2: tensor<?x?xf32>) -> tensor<?x?xf32> {
    %c1 = arith.constant 1 : index
    %c0 = arith.constant 0 : index
    %dim = tensor.dim %arg0, %c0 : tensor<?x?xf32>
    %dim_0 = tensor.dim %arg0, %c1 : tensor<?x?xf32>
    %dim_1 = tensor.dim %arg1, %c1 : tensor<?x?xf32>
    %extracted_slice = tensor.extract_slice %arg0[0, 0] [%dim, %dim_0] [1, 1] : tensor<?x?xf32> to tensor<?x?xf32>
    %extracted_slice_2 = tensor.extract_slice %arg1[0, 0] [%dim_0, %dim_1] [1, 1] : tensor<?x?xf32> to tensor<?x?xf32>
    %extracted_slice_3 = tensor.extract_slice %arg2[0, 0] [%dim, %dim_1] [1, 1] : tensor<?x?xf32> to tensor<?x?xf32>
    %0 = linalg.matmul ins(%extracted_slice, %extracted_slice_2 : tensor<?x?xf32>, tensor<?x?xf32>) outs(%extracted_slice_3 : tensor<?x?xf32>) -> tensor<?x?xf32>
    return %0 : tensor<?x?xf32>
  }
}
```

The revision early-return the case so we can get:

```mlir
func.func @matmul_tensors(%arg0: tensor<?x?xf32>, %arg1: tensor<?x?xf32>, %arg2: tensor<?x?xf32>) -> tensor<?x?xf32> {
  %0 = linalg.matmul ins(%arg0, %arg1 : tensor<?x?xf32>, tensor<?x?xf32>) outs(%arg2 : tensor<?x?xf32>) -> tensor<?x?xf32>
  return %0 : tensor<?x?xf32>
}
```

Reverts llvm/llvm-project#74543

The tests doesn't seem to work for NVIDIA so disabling it for now.

This API seems to be completely unused. Should we just remove it?

This patch fixes the erroneous multiple-target requirement in Fortran
offloading tests. Additionally, it adds two new variables
(`test_flags_clang`, `test_flags_flang`) to `lit.cfg` so that
compiler-specific flags for Clang and Flang can be specified.

Add a method for LLL basis reduction to the FracMatrix class.
This needs an abs() method for Fractions, which is added to Fraction.h.

This mask is an implementation detail of `FPBits` and shouldn't really
leak outside of it.