Revert "[Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values"

This reverts commit a3710589f285de0bb22ff92b1fc24df9411e986f.

[lldb] Read from the Rosetta shared cache with Xcode 14

Xcode 14 no longer puts the Rosetta expanded shared cache in a directory
named "16.0". Instead, it includes the real version number (e.g. 13.0),
the build string and the architecture, similar to the device support
directory names for iOS, tvOS and watchOS.

Currently, when there are multiple directories, we might end up picking
the wrong one in GetSDKDirectoryForCurrentOSVersion. The problem is that
without the build string we have no way to differentiate between
multiple directories with the same version number. This patch fixes the
problem by using GetOSBuildString which, as the name implies, returns
the build string if known.

This also adds a test for Rosetta debugging on Apple Silicon. Depending
on whether the Rosetta expanded shared cache is present, the test
ensures that there is or isn't a diagnostic about reading out of memory.

rdar://97576121

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

[RISCV] Add merge operand to RISCVISD::FCOPYSIGN_VL.

Similar to what was done for VRGATHER*_VL recently.

This will be used in D130659.

Call WatchpointList::RemoveAll in Target::Destroy.

I noticed that the test TestSetWatchpoint.py was failing every so often
on macOS.  The failure was in the last assert, that after destroying the
SBTarget containing it, the SBWatchpoint was still saying it was valid.

IsValid in this case just meant the watchpoint weak pointer could be turned
into a shared pointer.  The watchpoint shared pointers have two strong references
in general, one to the "Target::m_last_created_watchpoint", and one in the
Target::m_watchpoint_list.  Target::Destroy reset the last created watchpoint
but neglected to call RemoveAll on the watchpoint list (it does the analogous
work for the internal & external breakpoint lists...)  This patch does the
equivalent cleanup for the watchpoint list.

[Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values

DR2338 clarified that it was undefined behavior to set the value outside the
range of the enumerations values for an enum without a fixed underlying type.

We should diagnose this with a constant expression context.

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

[gn build] Port 6047deb7c2aa

[mlir][sparse] Add arith-expand pass to the sparse-compiler pipeline.

Modify an existing test to test the situation.

Reviewed By: Peiming

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

Revert "[llvm][NFC] Refactor code to use ProfDataUtils"

This reverts commit 300c9a78819b4608b96bb26f9320bea6b8a0c4d0.

We will reland once these issues are ironed out.

[llvm][NFC] Refactor code to use ProfDataUtils

In this patch we replace common code patterns with the use of utility
functions for dealing with profiling metadata. There should be no change
in functionality, as the existing checks should be preserved in all
cases.

Reviewed By: bogner, davidxl

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

[llvm] Provide utility function for MD_prof

Currently, there is significant code duplication for dealing with
MD_prof metadata throughout the compiler. These utility functions can
improve code reuse and simplify boilerplate code when dealing with
profiling metadata, such as branch weights. The inent is to provide a
uniform set of APIs that allow common tasks, such as identifying
specific types of MD_prof metadata and extracting branch weights.

Future patches can build on this initial implementation and clean up the
different implementations across the compiler.

Reviewed By: bogner

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

[GlobalISel] Handle IntToPtr constants in dbg.value

Currently, the IR to MIR translator can only handle two kinds of constant
inputs to dbg.values intrinsics: constant integers and constant floats. In
particular, it cannot handle pointers created from IntToPtr ConstantExpression
objects.

This patch addresses the limitation above by replacing the IntToPtr with
its input integer prior to converting the dbg.value input.

Patch by Felipe Piovezan!

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

[lldb][NFC] Pass ParsedDWARFTypeAttributes as const reference into ParseArrayType()

Fixes a FIXME

Reviewed By: zequanwu

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

workflows: Fix version check for X.0.0 releases

[LLDB][NFC] Fix possible resource leak

SymbolVendorPECOFF object is leaked on early return at line 110

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

workflows: Fix pull request creation for backports

This was broken by 17d4796cc84618e9b15f9484e5576127c431bc60.

[LinkerWrapper] Do not consume `--verbose` from the linker

Summary:
Linkers use `--verbose` to let users investigate search libraries among
other things. The linker wrapper was incorrectly not forwarding this to
the linker job. This patch simply renames this so users can still see
verbose messages from the linker if it was passed.

[Flang][Driver] Add support for AsmPrinter -mmlir options

This patch adds support for AsmPrinter  `-mmlir` options to the Flang driver.

Reviewed By: awarzynski

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

[libc++][chrono] Uses operator<=> in the calendar.

Since the calendar is added in C++20 the existing operators are removed.

Implements part of:
- P1614R2 The Mothership has Landed

Reviewed By: #libc, ldionne

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

[cross-project-tests] Add split-file as dependency

simplified_template_names_noncanonical_type_units.cpp uses split-file.

Reviewed By: dblaikie

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

[RISCV] Enable (scalable) vectorization by default

This change enables vectorization (using scalable vectorization only, fixed vectors are not yet enabled) for RISCV when vector instructions are available for the target configuration.

At this point, the resulting configuration should be both stable (e.g. no crashes), and profitable (i.e. few cases where scalar loops beat vector ones), but is not going to be particularly well tuned (i.e. we emit the best possible vector loop). The goal of this change is to align testing across organizations and ensure the default configuration matches what downstreams are using as closely as possible.

This exposes a large amount of code which hasn't otherwise been on by default, and thus may not have been fully exercised.  Given that, having issues fall out is not unexpected.  If you find issues, please make sure to include as much information as you can when reverting this change.

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

[clang-format] FIX: Misannotation 'auto' as trailing return type in lambdas

Lambdas with trailing return type 'auto' are annotated incorrectly. It causes a misformatting. The simpliest code to reproduce is:

```
auto list = {[]() -> auto { return 0; }};
```

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

Reviewed By: HazardyKnusperkeks, owenpan, curdeius

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

[gn build] Port 0f3f357e26cf

[clang-offload-bundler] Library-ize ClangOffloadBundler

Lifting the core functionalities of the clang-offload-bundler into a
user-facing library/API. This will allow online and JIT compilers to
bundle and unbundle files without spawning a new process.

This patch lifts the classes and functions used to implement
the clang-offload-bundler into a separate OffloadBundler.cpp,
and defines three top-level API functions in OfflaodBundler.h.
        BundleFiles()
        UnbundleFiles()
        UnbundleArchives()

This patch also introduces a Config class that locally stores the
previously global cl::opt options and arrays to allow users to call
the APIs in a multi-threaded context, and introduces an
OffloadBundler class to encapsulate the top-level API functions.

We also  lift the BundlerExecutable variable, which is specific
to the clang-offload-bundler tool, from the API, and replace
its use with an ObjcopyPath variable. This variable must be set
in order to internally call llvm-objcopy.

Finally, we move the API files from
clang/tools/clang-offload-bundler into clang/lib/Driver and
clang/include/clang/Driver.

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

[AMDGPU] Consider S_SETPRIO a scheduling boundary

The instruction is used to modify wave priority with the intent
to affect VALU execution and currently we can reschedule VALU
around it since that VALU does not have side effects.

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

[mlir][OpenMP] Add omp.atomic.update canonicalization

This patch adds canonicalization conditions for omp.atomic.update thus
eliminating it when it becomes just a write or a no-op due to other
changes during canonicalization.

Reviewed By: ftynse

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

[DebugInfo] Teach LLVM and LLDB about ptrauth in DWARF

Teach libDebugInfo (llvm-dwarfdump) and lldb about DWARF tags and
attributes for pointer authentication. These values have been emitted by
Apple clang for several releases. Although upstream LLVM doesn't emit
these values yet, we hope to upstream that part sometime soon.

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

[LV][RISCV] Add a test case for a quality problem mixing vector index and data types

The problem here is target independent, but particularly painful on RISCV.  If we chose to vectorize such that vscale x 2 x i32 is our widest type and fits in a register, a naive expansion of i64 comparisons results in comparisons and index types at <scalabe x 2 x i64>.  This requires both an LMUL of 2, and a VSETVLI toggle in the loop.  Note that we could have used <vscale x 2 x i32> for the compairons legally given the range of the trip count.

Use hasNItemsOrLess() in MRI::hasAtMostUserInstrs().

[VPlan] Mark VPPredInstPHIRecipe as not having side-effects.

Now that all uses of VPPredInstPHIRecipes are properly modeled, they can
be treated as not having side-effects, enabling removal.

[libc++] Implement P1004R2 (constexpr std::vector)

Reviewed By: #libc, ldionne

Spies: mgorny, var-const, ormris, philnik, miscco, hiraditya, steven_wu, jkorous, ldionne, christof, libcxx-commits

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

[AMDGPU] Precommit s_setprio scheduling test. NFC.

[clang][dataflow][NFC] Remove last use of deprecated ctor

Use a delegating constructor to remove the last use of the deprecated
ctor of `TypeErasedDataflowAnalysis`, and then delete it.

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

[ELF][test] Fix compressed-debug-level.test with zlib-ng

The test is brittle but it seems unnecessary to remove size check now.

Close #56222

[AArch64] Explicitly use v1i64 type for llvm.aarch64.neon.pmull64

Without this, the intrinsic will be expanded to an integer; thereby an
explicit copy (from GPR to SIMD register) will be codegen'd. This matches the
general convention of using "v1" types to represent scalar integer operations in
vector registers.

The similar approach is observed in D56616, and the pattern likely applies on
other intrinsic that accepts integer scalars (e.g.,
int_aarch64_neon_sqdmulls_scalar)

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

[libc++] Fixes the CI.

The GDB test was disabled for clang-15, updated the filter since main
now is clang-16.

[LV] Refresh an autogened test to pickup naming changes

[AArch64][GlobalISel] Add heuristics for localizing G_CONSTANT.

This adds similar heuristics to G_GLOBAL_VALUE, querying the cost of
materializing a specific constant in code size. Doing so prevents us from
sinking constants which require multiple instructions to generate into
use blocks.

Code size savings on CTMark -Os:
Program                                       size.__text
                                              before         after           diff
ClamAV/clamscan                               381940.00      382052.00       0.0%
lencod/lencod                                 428408.00      428428.00       0.0%
SPASS/SPASS                                   411868.00      411876.00       0.0%
kimwitu++/kc                                  449944.00      449944.00       0.0%
Bullet/bullet                                 463588.00      463556.00      -0.0%
sqlite3/sqlite3                               284696.00      284668.00      -0.0%
consumer-typeset/consumer-typeset             414492.00      414424.00      -0.0%
7zip/7zip-benchmark                           595244.00      594972.00      -0.0%
mafft/pairlocalalign                          247512.00      247368.00      -0.1%
tramp3d-v4/tramp3d-v4                         372884.00      372044.00      -0.2%
                           Geomean difference                               -0.0%

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

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 3

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com/projects/llvm:

1355854, 1347549, 1316348, 1372028, 1431625,
1315634, 1315637, 1355855, 1364803, 1420505,
1420563, 1420685, 1366014, 1203966, 1204029,
1204031, 1204032, 1328411, 1325969, 1325968,
1374921, 1094809

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

Allow data prefetch into non-default address space

I am playing with the LoopDataPrefetch pass and found out that it
bails to work with a pointer in a non-zero address space. This
patch adds the target callback to check if an address space is to
be considered for prefetching. Default implementation still only
allows address space 0, so this is NFCI.

This does not currently affect any known targets, but seems to be
generally useful for the future.

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

[Lit] Sort previously failed tests early

D98179 added a mechanism to sort tests by test time to run slow tests
early, increasing potential parallelism. It also added a feature where
negative tests would be marked as negative, allowing subsequent test
runs to run them earlier. Unfortunately it never actually stored the
negative time, even if all the other code seemed to be inplace to sort
them early. Luckily the fix seems simple.

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

Fix misc uses of "long" variables to use "int64_t".

I don't have any evidence these particular uses are actually causing any
issues, but we should avoid accidentally truncating immediate values
depending on the host.

[RISCV] Add isel pattern for (mul (and X, 0xffffffff), 3<<C) with Zba.

We can use slli.uw by C followed by sh1add. Similar can be done
for multiples of 5 and 9. We need to make sure that C is less than
32 to stay in bounds of the 5-bit immediate for slli.uw.

We have existing patterns for (mul X, 3<<C) that use sh1add
followed by slli. That order doesn't allow the and to be folded.

Reviewed By: reames

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

[RISCV] Disable constant hoisting for multiply by negated power of 2.

A mul by a negated power of 2 is a slli followed by neg. This doesn't
require any constant materialization and may be lower latency than mul.
The neg may also be foldable into other arithmetic.

Reviewed By: reames

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

[PowerPC] Change long to int64_t (which is always 64 bit or 8 bytes )

We can't guarantee the long always 64 bits like WINDOWS or LLP64 data
model (rare but we should consider).

So use int64_t from inttypes.h and safe in this case.

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

[libc] Change sinf range reduction to mod pi/16 to be shared with cosf.

Change `sinf` range reduction to mod pi/16 to be shared with `cosf`.

Previously, `sinf` used range reduction `mod pi`, but this cannot be used to implement `cosf` since the minimax algorithm for `cosf` does not converge due to critical points at `pi/2`.  In order to be able to share the same range reduction functions for both `sinf` and `cosf`, we change the range reduction to `mod pi/16` for the following reasons:
- The table size is sufficiently small: 32 entries for `sin(k * pi/16)` with `k = 0..31`.  It could be reduced to 16 entries if we treat the final sign separately, with an extra multiplication at the end.
- The polynomials' degrees are reduced to 7/8 from 15, with extra computations to combine `sin` and `cos` with trig sum equality.
- The number of exceptional cases reduced to 2 (with FMA) and 3 (without FMA).
- The latency is reduced while maintaining similar throughput as before.

Reviewed By: zimmermann6

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

[libc++][doc] Extended integral type support

This addresses a request during the review of D128929.

Reviewed By: ldionne, #libc

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

[libc++] Update clang-format style.

After evaluating the new style I noticed inner namespaces are now
indented. I am not fond of that style and I've seen some other review
comment in this regard so I propose we remove this option and use the
LLVM default not to indent it.

Reviewed By: ldionne, philnik, var-const, #libc

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

[RISCV][LV] Add basic tests for default configuration

All of our other tests are functionality tests constrained to some
specific configuration.  This one is intended to float with the
default configuration so that changes in that default are visible
in reviews.  Note that our current default does not enable
vectorization at all; thus the current output is unvectorized.

[mlir][sparse] fix error when sparse kernel is nested in a scf structrual operator.

Sparse compiler failed on the provided test (when the sparse kernel is nested in a scf structrual operator).

Reviewed By: bixia

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

[flang] Support the color diagnostics on scanning, parsing, and semantics

The options -f{no-}color-diagnostics have been supported in driver. This
supports the behaviors in scanning, parsing, and semantics, and the
behaviors are exactly the same as the driver.

To illustrate the added behaviour, consider the following input file:
```! file.f90
program m
  integer :: i = k
end
```
In the following invocations, "error: Must be a constant value" _will be_
formatted:
```
$ flang-new file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
    integer :: i = k
```
Note that "error: Semantic errors in file.f90" is also formatted, which
is supported in https://reviews.llvm.org/D126164.

Also note that only "error", "warning" and "portability" are formatted.
Check the following input file:
```! file2.f90
program m
  integer :: i =
end
```
```
$ flang-new test2.f90
error: Could not parse test2.f90
./test2.f90:2:11: error: expected '('
    integer :: i =
            ^
./test2.f90:2:3: in the context: statement function definition
    integer :: i =
    ^
...
```
The "error: Could not parse test2.f90" and "error: expected '('" are
formatted. Others such as "in the context" are not formatted yet, which
may or may not be supported.

Reviewed By: awarzynski

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

[libc++][doc] Updates format status page.

Remove some no longer relevant details and adds the C++23 papers voted
in at the last plenary.

[NFC][flang] Add FIXME for privatization of loop bounds in Bridge.cpp

There is post comment of adding TODO/FIXME for privatization of loop
bounds in D127137. D127137 fixes the bug in OpenMP firstprivate clause,
which should be refactored later according to the post comment. Add
FIXME for it.

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

[AggressiveInstCombine] check sqrt operand to allow more libcall->intrinsic transforms

This should fix issue #56383 (at least when compiled with -O3 because this pass is only
run at -O3 currently).

[AggressiveInstCombine] add tests for sqrt with known positive operand; NFC

[AArch64][SVE] Add Gather Index narrowing tests

[libc++][doc] Updates status documents.

Adds the papers and LWG issues voted in during the July 2022 plenary.

Note the updating of the project based statuses is left to the active
contributors of these projects.

Reviewed By: #libc, huixie90, philnik

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

[amdgpu][nfc] Fix build with a certan Clang version

It errors out in the Bazel CI:

AMDGPULowerModuleLDSPass.cpp:384:12: error: chosen constructor is
explicit in copy-initialization
    return {SGV, std::move(Map)};

Reviewed By: rupprecht

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

[NFC][flang] Remove the unused header in Bridge.cpp

The header file OpenMPDialect.h is added in Bridge.cpp in D130027,
but it is unused. Remove it.

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

Revert "[OpenMP] Remove noinline attributes in the device runtime"

The behaviour of this patch is not great, but it has some side-effects
that are required for OpenMPOpt to work. The problem is that when we use
`-mlink-builtin-bitcode` we only import used symbols from the runtime.
Then OpenMPOpt will insert calls to symbols that were not previously
included. This patch removed this implicit behaviour as these functions
were kept alive by the `noinline` simply because it kept calls to them
in the module. This caused regression in some tests that relied on some
OpenMPOpt passes without using LTO. Reverting for the LLVM15 release but
will try to fix it more correctly on main.

This reverts commit d61d72dae604c3258e25c00622b1a85861450303.

Fixes #56752

[LV] Add missing uses to test to make them more robust.

The changes ensure the VPPredInstPHIRecipes are actually used and cannot
be remove by VP-DCE.

[libLTO] Set data-sections by default in libLTO.

This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.

This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.

Reviewed By: w2yehia, MaskRay

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

[bazel] Port 5caa941f683270c3e5078ec46f208212b565c505

Revert "[libLTO] Set data-sections by default in libLTO."

This reverts commit f565444b486d49f84297c3a279ca24d785961ea8.

Revert "ManagedStatic: remove from ASTMatchersInternal.h"

This reverts commit 7132bcdc428d79258901af0156ace240952b6745.

It is the likely cause of a clang-tools-extra test regression. Reverting
until I can investigate what's going on.

[Bazel] Bump to v16.0.0, corresponding to llvmorg-16-init

[libLTO] Set data-sections by default in libLTO.

This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.

This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.

Reviewed By: w2yehia, MaskRay

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

[mlir][complex] Custom attribute comlex.number.

Add custom attribute for complex dialect. Although this commit does not have significant impact on the conversion framework, it will lead us to construct complex numbers in a readable and tidy manner.

Related discussion: https://reviews.llvm.org/D127476

Reviewed By: pifon2a, akuegel

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

[DAG] SimplifyDemandedBits - ensure we clear known One bits that AssertZext asserts are really known Zero

Matches ComputeKnownBits behaviour

Thanks to @uabelho for the fuzz regression report on D129765

ManagedStatic: remove from ASTMatchersInternal.h

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

clang: include ManagedStatic.h for llvm_shutdown

The code relied on ManagedStatic.h being included indirectly. This is
about to change as uses of ManagedStatic are removed throughout the
codebase.

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

ClangLinkerWrapper: explicitly #include <atomic>

This code relied on implicitly having std::atomic available via the
ManagedStatic.h header.

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

[mlir][LLVM] Fix incorrect GEP fold with struct constants

The fold in it's current state only checks whether the amount of dynamic indices is 1. This does however not check for the presence of any struct indices, leading to an incorrect fold.

This patch fixes that issue by checking that struct indices are 1, which in addition to the pre-existing check that dynamic indices are 1, guarantees that the single index is a dynamic one.

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

[lldb] Always use APFloat for FP dumping

The DumpDataExtractor function had two branches for printing floating
point values. One branch (APFloat) was used if we had a Target object
around and could query it for the appropriate semantics. If we didn't
have a Target, we used host operations to read and format the value.

This patch changes second path to use APFloat as well. To make it work,
I pick reasonable defaults for different byte size. Notably, I did not
include x87 long double in that list (as it is ambibuous and
architecture-specific). This exposed a bug where we were printing
register values using the target-less branch, even though the registers
definitely belong to a target, and we had it available. Fixing this
prompted the update of several tests for register values due to slightly
different floating point outputs.

The most dubious aspect of this patch is the change in
TypeSystemClang::GetFloatTypeSemantics to recognize `10` as a valid size
for x87 long double. This was necessary because because sizeof(long
double) on x86_64 is 16 even though it only holds 10 bytes of useful
data. This generalizes the hackaround present in the target-free branch
of the dumping function.

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

[trace] Add instruction control flow kind to JSON trace dumper's output

D128477 adds a '-k' flag which displays each instruction's control flow in the `thread trace dump instructions` command's non-json  output (ie no '-j' or '-J' flag)
This diff adds the instruction control flow kind to the `thread trace dump instructions` command's JSON output (ie '-j' or '-J' flag)

Test Plan:
Confirm "controlFlowKind" is present in JSON when '-k' is provided
```
(lldb) thread trace dump instructions -J -k
[
  {                                                                                                                                                                                                                                                                                 [141/1952]
    "id": 7755,
    "loadAddress": "0x400868",
    "module": "test.out",
    "symbol": "main",
    "mnemonic": "jmp",
    "controlFlowKind": "jump",
    "source": "/home/jakobjohnson/jakob-dev/test.cpp",
    "line": 41,
    "column": 29
  },
  {
    "id": 7753,
    "loadAddress": "0x7ffff7b54dab",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "retq",
    "controlFlowKind": "return"
  },
  {
    "id": 7752,
    "loadAddress": "0x7ffff7b54daa",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "popq",
    "controlFlowKind": "other"
  },
  ...
]
```
Confirm "controlFlowKind" is not present when '-k' isn't provided
```
(lldb) thread trace dump instructions -J
[
  {
    "id": 7755,
    "loadAddress": "0x400868",
    "module": "test.out",
    "symbol": "main",
    "mnemonic": "jmp",
    "source": "/home/jakobjohnson/jakob-dev/test.cpp",
    "line": 41,
    "column": 29
  },
  {
    "id": 7753,
    "loadAddress": "0x7ffff7b54dab",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "retq"
  },
  {
    "id": 7752,
    "loadAddress": "0x7ffff7b54daa",
    "module": "libstdc++.so.6",
    "symbol": "std::ostream::flush()",
    "mnemonic": "popq"
  },
```

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

[gn build] (semi-manually) port 6bdb15fe844c

Sinking or hoisting instructions between loops before fusion

Instructions between two adjacent loops will be hoisted above the first
loop, or sunk below the second to facilitate loop fusion. Hoisting will
be attempted for an instruction that dominates the first loop.
Otherwise, sinking this instructions will be attempted.

Instructions with side effects will not be considered for sinking or
hoisting. Hoisting/sinking of any instructions between loops will only
be performed if all the instructions can be moved. As well,
sinking/hoisting is considered for each instruction in isolation,
without taking into account sinking/hoisting decisions for other
instructions in the preheader.

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

[clang][ExtractAPI] Fix objc_property.m reference output

After landing 7f0387de4c600af185b2db8d748f530444fe03cd I forgot to update this
new test.

[CMake] Enable -z defs on Solaris

I wondered why I hadn't seen the link failures in D130571
<https://reviews.llvm.org/D130571> on Solaris/sparcv9 and found that
Solaris, unlike Linux, doesn't use `-Wl,-z,defs` when linking shared
objects.  The three affected shared objects indeed have undefined
references to several 64-bit atomics.

This patch will expose such issues in the future by defaulting to
`-Wl,-z,defs` on Solaris, as recommended in `ld(1)`.

Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.

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

[Sema] Return primary merged decl as canonical for concepts

Otherwise we get invalid results for ODR checks. See changed test for an
example: despite the fact that we merge the first concept, its **uses**
were considered different by `Profile`, leading to redefinition errors.

After this change, canonical decl for a concept can come from a
different module and may not be visible. This behavior looks suspicious,
but does not break any tests. We might want to add a mechanism to make
the canonical concept declaration visible if we find code that relies on
this invariant.

Additionally make sure we always merge with the canonical declaration to
avoid chains of merged concepts being reported as redefinitions. An
example was added to the test.

Also change the order of includes in the test. Importing a moduralized
header before its textual part causes the include guard macro to be
exported and the corresponding `#include` becomes a no-op.

Reviewed By: ChuanqiXu

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

[flang] Disable pipefail for tests for stdin input

We have seen the llvm test fail every so often on our bots:
https://lab.llvm.org/buildbot/#/builders/173/builds/6711

This happens because `flang-new -fc1 -S` does not wait for the
pipe to finish being written to/does not read out all the content.
You can see this in the output, cat comes after flang:
+ /home/tcwg-buildbot/worker/flang-aarch64-release/build/bin/not /home/tcwg-buildbot/worker/flang-aarch64-release/build/bin/flang-new -fc1 -S - -o -
+ cat /home/tcwg-buildbot/worker/flang-aarch64-release/llvm-project/flang/test/Driver/input-from-stdin-llvm.ll
error: Invalid input type - expecting a Fortran file

This means that cat gets SIGPIPE which causes it to exit with
code 141 and that's the final result due to pipefail.

flang isn't wrong to exit early (I think some modes of grep also do this)
and we only care about flang's exit code. So disable pipefail for
the stdin testing.

Reviewed By: awarzynski

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

[compiler-rt][Sanitizer] Link sanitizer libs with -latomic on SPARC

When building on Linux/sparc64, the 32-bit `libclang_rt.asan.so`,
`libclang_rt.ubsan_minimal.so`, and `libclang_rt.ubsan_standalone.so`
failed to link with undefined references to 64-bit atomics, which `clang`
cannot inline.  Even D130569 <https://reviews.llvm.org/D130569> didn't help
because those libraries are linked with `-nodefaultlibs`, so dependent
libraries need to be added explicitly.

That's what this patch does.

Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`.

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

[flang] Single entry point for GET_COMMAND_ARGUMENT

This patch refactors the runtime support for GET_COMMAND_ARGUMENT to
have a single entry point instead of 2. It also updates lowering
accordingly.

This makes it easier to handle dynamically optional arguments. See also
https://reviews.llvm.org/D118777

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

[RISCV]Enable isIntDivCheap when attribute is minsize

Don't expand divisions by constants when attribute is minsize.

Reviewed By: craig.topper

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

[Support] Handle SPARC in sys::getHostCPUName

While working on D118450 <https://reviews.llvm.org/D118450>, I noticed that
`sys::getHostCPUName` lacks SPARC support.

This patch implements it.  The code is taken from/inspired by GCC's
`gcc/config/sparc/driver-sparc.cc`.  There's one caveat: since LLVM, unlike
GCC, doesn't support the SPARC-M7, -S7, and -M8 CPUs, I map all those to
the latest supported one (UltraSparc T4/`niagara4`).

Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu` by
running `savcov --version` on

- Netra SPARC S7-2 (SPARC-S7, Solaris 11.4)
- SPARC T5-2 (SPARC T5, Solaris 11.4)
- SPARC Enterprise T5220 (UltraSPARC T2, Solaris 11.3)
- SPARC T5 (UltraSPARC T5, Debian sid)
- SPARC T3 (UltraSPARC T3, Debian sid)
- SPARC Enterprise T5220 (Debian sid)

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

[clang][ExtractAPI] Ensure that class properties have a kind of "Type Property"

Generated symbol graphs should distinguish between type properties and instance
properties.

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

[clang][ExtractAPI] Add a space between type and name in property declaration fragments

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

[DAG] SimplifyDemandedBits - don't early-out for multiple use values

SimplifyDemandedBits currently early-outs for multi-use values beyond the root node (just returning the knownbits), which is missing a number of optimizations as there are plenty of cases where we can still simplify when initially demanding all elements/bits.

@lenary has confirmed that the test cases in aea-erratum-fix.ll need refactoring and the current increase codegen is not a major concern.

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

[mlir] update Bazel for e99fae899710b041994cef4beb6764f8dfbe8ef0

[clang-tidy] Add execute perms back to add_new_check script

[CSKY] Fix the btsti16 instruction missing in generic processor

Normally, generic processor does not have any SubtargetFeature. And it
can just generate most basic instructions which have no Predicates to
guard.

But it needs to enbale predicate for the btsti16 instruction as one of the most basic instructions.
Or the generic processor can't finish codegen process. So Add FeatureBTST16 SubtargetFeature to generic ProcessorModel.

[ARM] Test more atomic sizes with +atomics-32 feature (NFC)

Check that 8-bit and 16-bit atomics also work as expected. Also
fix the alignment on the 64-bit tests -- testing unaligned atomics
wasn't intended here.

Update ProgrammersManual STL docs

The SGI page doesn't exist anymore and isn't really relevant at this day
and age.

While at it, added the "other" main C++ website and moved all URLs to
HTTPS.

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

---

Troubleshooting list to deal with any breakage seen with this patch:

1) The most likely effect one would see by this patch is a change in how
   a type is printed. The type printer will, by design and default,
   print types as written. There are customization options there, but
   not that many, and they mainly apply to how to print a type that we
   somehow failed to track how it was written. This patch fixes a
   problem where we failed to distinguish between a type
   that was written without any elaborated-type qualifiers,
   such as a 'struct'/'class' tags and name spacifiers such as 'std::',
   and one that has been stripped of any 'metadata' that identifies such,
   the so called canonical types.
   Example:
   ```
   namespace foo {
     struct A {};
     A a;
   };
   ```
   If one were to print the type of `foo::a`, prior to this patch, this
   would result in `foo::A`. This is how the type printer would have,
   by default, printed the canonical type of A as well.
   As soon as you add any name qualifiers to A, the type printer would
   suddenly start accurately printing the type as written. This patch
   will make it print it accurately even when written without
   qualifiers, so we will just print `A` for the initial example, as
   the user did not really write that `foo::` namespace qualifier.

2) This patch could expose a bug in some AST matcher. Matching types
   is harder to get right when there is sugar involved. For example,
   if you want to match a type against being a pointer to some type A,
   then you have to account for getting a type that is sugar for a
   pointer to A, or being a pointer to sugar to A, or both! Usually
   you would get the second part wrong, and this would work for a
   very simple test where you don't use any name qualifiers, but
   you would discover is broken when you do. The usual fix is to
   either use the matcher which strips sugar, which is annoying
   to use as for example if you match an N level pointer, you have
   to put N+1 such matchers in there, beginning to end and between
   all those levels. But in a lot of cases, if the property you want
   to match is present in the canonical type, it's easier and faster
   to just match on that... This goes with what is said in 1), if
   you want to match against the name of a type, and you want
   the name string to be something stable, perhaps matching on
   the name of the canonical type is the better choice.

3) This patch could expose a bug in how you get the source range of some
   TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
   which only looks at the given TypeLoc node. This patch introduces a new,
   and more common TypeLoc node which contains no source locations on itself.
   This is not an inovation here, and some other, more rare TypeLoc nodes could
   also have this property, but if you use getLocalSourceRange on them, it's not
   going to return any valid locations, because it doesn't have any. The right fix
   here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
   into the inner TypeLoc to get the source range if it doesn't find it on the
   top level one. You can use getLocalSourceRange if you are really into
   micro-optimizations and you have some outside knowledge that the TypeLocs you are
   dealing with will always include some source location.

4) Exposed a bug somewhere in the use of the normal clang type class API, where you
   have some type, you want to see if that type is some particular kind, you try a
   `dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
   ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
   Again, like 2), this would usually have been tested poorly with some simple tests with
   no qualifications, and would have been broken had there been any other kind of type sugar,
   be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
   The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
   into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
   For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.

5) It could be a bug in this patch perhaps.

Let me know if you need any help!

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D112374

[pseudo] Fix initializer of string table

Apparently new string[/*no size*/]{"foo", "bar"} is a clang/gcc extension?

[flang][NFC] Unify check prefixes in `abstract-results.fir` test

Now the prefixes have the same length
and they'll be easier to distinguish when
`GlobalOp` tests will be added

Depends on D129778

Reviewed By: clementval

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

[flang] Generalize `AbstractResultOpt` pass

This change decouples common functionality for convering abstract
results, so it can be reused later.

Depends on D129485

Reviewed By: clementval, jeanPerier

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

[mlir] more aggressive folding in tiling/fusion transformations

Combine the recently added utilities for folded-by-construction affine
operations with the attribute-based Range to enable more folding. This
decreases the amount of emitted code but has little effect on test
precisely because the tests are not checking for the spurious constants.
The difference in the shape of affine maps comes from the internals of
affine folding.

Depends on D129633

Reviewed By: nicolasvasilache

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

[mlir] Make ViewLikeInterface Range work with attributes

While most of methods in ViewLikeInterface accept an `OpFoldResult` for
the offset/size/stride that may be static, represented as `Attribute`,
or dynamic, represented as `Value`, the `Range` abstraction only
accepted `Values`. This can often lead to known-constant
offset/size/strides being materialized into constant operations and
hinder further constant propagation without explicitly running the
constant folding pass. This often leads to a more complicated than
necessary addressing code being emitted. Switch `Range` to use
`OpFoldResult`. Code that uses `Range` currently keeps materializing the
constants to minimize the effect of this change on the IR. Further
commits will make use of this.

Reviewed By: nicolasvasilache, mravishankar

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

[mlir] Partially port splitting transform to TilingInterface

The structured op splitting transformation is conceptually similar to
tiling in the sense that it decomposes the iteration space of the
original op into several parts. Therefore, it is possible to implement
it using the TilingInterface to operate on iteration spaces and their
parts. However, the implementation also requires to pass updated input
operands, which is not supported by the interface, so the implementation
currently remains Linalg-specific.

Reviewed By: mravishankar

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

Revert "[Debuginfo][llvm-dwarfutil] Add check for unsupported debug sections."

This reverts commit 0d191b7553e7efbf7ce57c77274b83c15b681933.