This reverts commit 171f7024.

Reverting this patch because it causes a cyclic dependency in the module build

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/48197/consoleFull#-69937453049ba4694-19c4-4d7e-bec5-911270d8a58c

In file included from <module-includes>:1:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/Argument.h:18:10: fatal error: cyclic dependency in module 'LLVM_IR': LLVM_IR -> LLVM_intrinsic_gen -> LLVM_IR
         ^
While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:
While building module 'LLVM_IR' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57:
In file included from <module-includes>:12:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/DebugInfo.h:24:10: fatal error: could not build module 'LLVM_intrinsic_gen'
 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:
In file included from <module-includes>:15:
In file included from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCContext.h:23:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57:10: fatal error: could not build module 'LLVM_IR'
 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:10: fatal error: could not build module 'LLVM_MC'
 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
4 errors generated.

This reverts commit 028df7fa.

I am reverting this patch because I need to revert 171f7024 and without reverting this patch, reverting 171f7024 causes conflicts.

 Patch 171f7024 introduced a cyclic dependancy in the module build.

    https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/48197/consoleFull#-69937453049ba4694-19c4-4d7e-bec5-911270d8a58c

    In file included from <module-includes>:1:
    /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/Argument.h:18:10: fatal error: cyclic dependency in module 'LLVM_IR': LLVM_IR -> LLVM_intrinsic_gen -> LLVM_IR
             ^
    While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:
    While building module 'LLVM_IR' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57:
    In file included from <module-includes>:12:
    /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/DebugInfo.h:24:10: fatal error: could not build module 'LLVM_intrinsic_gen'
     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
    While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:
    In file included from <module-includes>:15:
    In file included from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCContext.h:23:
    /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57:10: fatal error: could not build module 'LLVM_IR'
     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
    /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:10: fatal error: could not build module 'LLVM_MC'
     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
    4 errors generated.

This reverts commit 4c44fa1c.

This patch has to be reverted because I need to revert 171f7024 and without reverting this patch, reverting 171f7024 causes conflicts.

Patch 171f7024 introduced a cyclic dependency in the module build.

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/48197/consoleFull#-69937453049ba4694-19c4-4d7e-bec5-911270d8a58c

In file included from <module-includes>:1:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/Argument.h:18:10: fatal error: cyclic dependency in module 'LLVM_IR': LLVM_IR -> LLVM_intrinsic_gen -> LLVM_IR
         ^
While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:
While building module 'LLVM_IR' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57:
In file included from <module-includes>:12:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/IR/DebugInfo.h:24:10: fatal error: could not build module 'LLVM_intrinsic_gen'
 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
While building module 'LLVM_MC' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:
In file included from <module-includes>:15:
In file included from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCContext.h:23:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/MC/MCPseudoProbe.h:57:10: fatal error: could not build module 'LLVM_IR'
 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/lib/MC/MCAsmInfoCOFF.cpp:14:10: fatal error: could not build module 'LLVM_MC'
 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
4 errors generated.

Clang supports indirect call Control-Flow Integrity (CFI) sanitizers
(e.g. -fsanitize=cfi-icall), which enforce an exact type match
between a function pointer and the target function. Unfortunately,
Clang doesn't provide diagnostics that help developers avoid
function pointer assignments that can lead to runtime CFI
failures. -Wincompatible-function-pointer-types doesn't warn about
enum to integer mismatches if the types are otherwise compatible, for
example, which isn't sufficient with CFI.

Add -Wincompatible-function-pointer-types-strict, which checks for a
stricter function type compatibility in assignments and helps warn about
assignments that can potentially lead to CFI failures.

Reviewed By: aaron.ballman, nickdesaulniers

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

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

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

It needs to run after edits from config files are applied to
the compile command (because the config file may specify the
compiler), and before resolveDriver() runs at the end of
CommandMangler.

As part of this change, QueryDriverDatabase is renamed to
SystemIncludeExtractor and is no longer a GlobalCompilationDatabase.

Fixes https://github.com/clangd/clangd/issues/1089
Fixes https://github.com/clangd/clangd/issues/1173
Fixes https://github.com/clangd/clangd/issues/1263

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

This gives CommandMangler access to other fields of
tooling::CompileCommand as well, e.g. Directory.

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

libstuff-based tools (e.g. `codesign` and `strip`) require
`__chainfixups` to be the first section in `__LINKEDIT`, and print a
"file not in an order that can be processed" error message if that is
not the case.

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

Issue #58858: when linking libomp.so, exports_so.txt has non-existent/undefined
symbols which cause errors to ld --no-undefined-version. Use
-Wl,--undefined-version if available (gold, ld.lld, future GNU ld 2.40).

Allowing incorrect version scripts is not a helpful default. Flip that
to help users find their bugs at build time rather than at run time.

Reviewed By: MaskRay

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

In the code
const char *str = "abc"
if you do sizeof(str) you get the size of the pointer, not the string.
This patch fixes that mistake.

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

This change makes `this` a reference instead of a pointer in
HLSL. HLSL does not have the `->` operator, and accesses through `this`
are with the `.` syntax.

Tests were added and altered to make sure
the AST accurately reflects the types.

Reviewed By: aaron.ballman

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

This patch adds the basic conversion facilities to scanf as well as unit
tests for them. It also adds scanf_main which will be used for the
eventual scanf entrypoints.

Reviewed By: sivachandra

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

This is the interface that will be used to read from a file or string in
scanf. This patch also adds the string and file implementations of the
reader, although the file reader is not yet complete since ungetc has
not yet been implemented.

Reviewed By: sivachandra

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

Reviewed By: michaelrj

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

[mlir][sparse] extend foreach operation to accept reduction arguments; fix sparse tensor rewriting patterns that do not propagate sparse tensor SSA properly.

This patch re-commit D137468 and D137463, which were reverted by mistakes.

Reviewed By: aartbik

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

Reviewed By: michaelrj, lntue

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

Fixes weird clang-format indentation with an upcoming patch.

Explicitly call `LLVMContext::setOpaquePointers` in `CodeGenAction`
before loading any IR files. With this we use the mode specified on the
command-line rather than lazily initializing it based on the contents of
the IR.

This helps when using `-fthinlto-index` which may end up mixing files
with typed and opaque pointer types which fails when the first file
happened to use typed pointers since we cannot downgrade IR with opaque
pointer types to typed pointer types.

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

Previously, the printf parser would treat "%\0" as a conversion with the
name "\0", and advance past the null byte causing a buffer overflow.
This patch corrects that in both printf and scanf.

Reviewed By: sivachandra

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

This was treating all calls as uniform by default, which
is wrong if used to read a VGPR.

Reviewed By: Michael137

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

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: shafik

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

For a local linkage GlobalObject in a non-prevailing COMDAT, it remains defined while its
leader has been made available_externally. This violates the COMDAT rule that
its members must be retained or discarded as a unit.

To fix this, update the regular LTO change D34803 to track local linkage
GlobalValues, and port the code to ThinLTO (GlobalAliases are not handled.)

This fixes two problems.

(a) `__cxx_global_var_init` in a non-prevailing COMDAT group used to
linger around (unreferenced, hence benign), and is now correctly discarded.
```
int foo();
inline int v = foo();
```

(b) Fix https://github.com/llvm/llvm-project/issues/58215:
as a size optimization, we place private `__profd_` in a COMDAT with a
`__profc_` key. When FuncImport.cpp makes `__profc_` available_externally due to
a non-prevailing COMDAT, `__profd_` incorrectly remains private. This change
makes the `__profd_` available_externally.

```
cat > c.h <<'eof'
extern void bar();
inline __attribute__((noinline)) void foo() {}
eof
cat > m1.cc <<'eof'
#include "c.h"
int main() {
  bar();
  foo();
}
eof
cat > m2.cc <<'eof'
#include "c.h"
__attribute__((noinline)) void bar() {
  foo();
}
eof

clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw

clang -O2 -fprofile-generate=./t m1.cc m2.cc -flto=thin -fuse-ld=lld -o t_gen
rm -fr t && ./t_gen && llvm-profdata show -function=foo t/default_*.profraw
```

If a GlobalAlias references a GlobalValue which is just changed to
available_externally, change the GlobalAlias as well (e.g. C5/D5 comdats due to
cc1 -mconstructor-aliases). The GlobalAlias may be referenced by other
available_externally functions, so it cannot easily be removed.

Depends on D137441: we use available_externally to mark a GlobalAlias in a
non-prevailing COMDAT, similar to how we handle GlobalVariable/Function.
GlobalAlias may refer to a ConstantExpr, not changing GlobalAlias to
GlobalVariable gives flexibility for future extensions (the use case is niche.
For simplicity we don't handle it yet). In addition, available_externally
GlobalAlias is the most straightforward implementation and retains the aliasee
information to help optimizers.

Reviewed By: tejohnson

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

This patch fix the re-revert D135927 (which caused a windows build failure) to re-enable parallel for/reduction. It also fix a warning caused by D137442.

Reviewed By: aartbik

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

This patch fixes:

  mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp:717:48:
  error: comparison of integers of different signs: 'int64_t' (aka
  'long') and 'uint64_t' (aka 'unsigned long')
  [-Werror,-Wsign-compare]

Lower async.func with async.coro and async.runtime operations

- This patch modifies AsyncToAsyncRuntime pass to add lowering async.func ops with coroutine cfg.
Example:

```
async.func @foo() -> !async.value<f32> {
  %cst = arith.constant 42.0 : f32
  return %cst: f32
}
```

After lowering:

```
func.func @foo() -> !async.value<f32> attributes {passthrough = ["presplitcoroutine"]} {
    %0 = async.runtime.create : !async.value<f32>
    %1 = async.coro.id
    %2 = async.coro.begin %1
    cf.br ^bb1
  ^bb1:  // pred: ^bb0
    %cst = arith.constant 4.200000e+01 : f32
    async.runtime.store %cst, %0 : <f32>
    async.runtime.set_available %0 : !async.value<f32>
    cf.br ^bb2
  ^bb2:  // pred: ^bb1
    async.coro.free %1, %2
    cf.br ^bb3
  ^bb3:  // pred: ^bb2
    async.coro.end %2
    return %0 : !async.value<f32>
}
```

Reviewed By: ezhulenev

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

Remove GlobalISel test files that only contained RUN lines running the
code from the SelectionDAG version of the same test.

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

This reverts commit 53d5d340.

This is causing a build failure on the windows mlir bot that was previously hidden by another sparse tensor change that caused failures:

https://lab.llvm.org/buildbot/#/builders/13/builds/28006

Previously the response file expansion code would print the error, but
lld would not exit, which was odd.

lld does response file expansion in the different drivers, but it's also
done in main() first, so it's enough to check there.

By checking for these errors we would have caught when D136090
introduced a bug that made lld print errors for response files which
contained "-rpath @foo".

Differental revision: https://reviews.llvm.org/D137477

Added MathOptionsBase to share fastmath config between different
components. Frontend driver translates LangOptions into MathOptionsBase.
FirConverter configures FirOpBuilder using MathOptionsBase
config passed to it via LoweringOptions.

Depends on D137390

Reviewed By: jeanPerier

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

Reviewed By: jeanPerier, PeteSteinfeld

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

Add the missing include to fix an error when `cmake_push_check_state()`
is called and incidentally the CMakePushCheckState module is not loaded
by any other check running prior to `FindLibEdit.cmake`:

    CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state):
      Unknown CMake command "cmake_push_check_state".
    Call Stack (most recent call first):
      cmake/modules/LLDBConfig.cmake:52 (find_package)
      cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency)
      CMakeLists.txt:28 (include)

Gentoo Bug: https://bugs.gentoo.org/880065

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