Since the CI is broken, I didn't investigate why it happened. It just
fixes it.

Getting compile units for data addresses is much slower, as it often
requires a slow fallback path to walk every DWARF entry, as
data addresses don't fall into the compilation unit ranges.

Most lookups are code addresses, and don't need this logic. Split the
functionality out so that we restore the fast-path behaviour for the
code lookups.

More context at:
https://discourse.llvm.org/t/llvm-symbolizer-has-gotten-extremely-slow/67262

Reviewed By: dblaikie

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

After the work in a538d1f1 5351878b 372240df, and
subsequently cleanup of all the in-tree targets, we can now delete the
support for positional operand matching!

This removes three options which could previously be set in a
Target's "InstrInfo" tablegen definition:
- useDeprecatedPositionallyEncodedOperands
- decodePositionallyEncodedOperands
- noNamedPositionallyEncodedOperands

(Also announced at https://discourse.llvm.org/t/tablegen-deleting-deprecated-positional-instruction-operand-matching-support/68524)

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

This updates most (all?) error-diagnostic-emitting python APIs to
capture error diagnostics and include them in the raised exception's
message:
```
>>> Operation.parse('"arith.addi"() : () -> ()'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
mlir._mlir_libs.MLIRError: Unable to parse operation assembly:
error: "-":1:1: 'arith.addi' op requires one result
 note: "-":1:1: see current operation: "arith.addi"() : () -> ()
```

The diagnostic information is available on the exception for users who
may want to customize the error message:
```
>>> try:
...   Operation.parse('"arith.addi"() : () -> ()')
... except MLIRError as e:
...   print(e.message)
...   print(e.error_diagnostics)
...   print(e.error_diagnostics[0].message)
...
Unable to parse operation assembly
[<mlir._mlir_libs._mlir.ir.DiagnosticInfo object at 0x7fed32bd6b70>]
'arith.addi' op requires one result
```

Error diagnostics captured in exceptions aren't propagated to diagnostic
handlers, to avoid double-reporting of errors. The context-level
`emit_error_diagnostics` option can be used to revert to the old
behaviour, causing error diagnostics to be reported to handlers instead
of as part of exceptions.

API changes:
- `Operation.verify` now raises an exception on verification failure,
  instead of returning `false`
- The exception raised by the following methods has been changed to
  `MLIRError`:
  - `PassManager.run`
  - `{Module,Operation,Type,Attribute}.parse`
  - `{RankedTensorType,UnrankedTensorType}.get`
  - `{MemRefType,UnrankedMemRefType}.get`
  - `VectorType.get`
  - `FloatAttr.get`

closes #60595

depends on D144804, D143830

Reviewed By: stellaraccident

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

Reland "[lldb][TypeSystemClang] Use the CXXFunctionPointerSummaryProvider for member-function pointers"

With this patch member-function pointers are formatted using
`CXXFunctionPointerSummaryProvider`.

This turns,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
into
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94 (a.out`Foo::member_func() at main.cpp:3)
```

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

Before this patch, LLDB used to format pointers to members, such as,
```
void (Foo::*pointer_to_member_func)() = &Foo::member_func;
```
as `eFormatBytes`. E.g.,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) $1 = 94 3f 00 00 01 00 00 00 00 00 00 00 00 00 00 00
```

This patch makes sure we format pointers to member functions the same
way we do regular function pointers.

After this patch we format member pointers as:
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```

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

Currently empty arguments are not respected. They are silently dropped
in two places: (1) when extracting them from the target.run-args
setting and (2) when constructing the lldb-argdumper invocation.

(1) is actually a regression from a few years ago. We did not always
drop empty arguments. See 31d97a5c.

rdar://106279228

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

Change lldb-vscode to use the `expression` command for generating completions, instead
of the `p` alias.

Aliases are user overrideable, and even deletable, but the `expression` command is
unchangeable.

See D141539 where a similar replacement was done to tests.

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

[Flang][OpenMP][MLIR][Driver][bbc] Add -fopenmp-is-device flag to Flang -fc1 & the bbc tool, and omp.is_device attribute

Adds the -fopenmp-is-device flag to bbc and Flang's -fc1 (but not flang-new) and in addition adds an omp.is_device attribute onto the module when fopenmp is passed, this is a boolean attribute that is set to false or true dependent on if fopenmp-is-device is specified alongside the fopenmp flag on the commandline when invoking flang or bbc.

Reviewers:
awarzynski
kiranchandramohan

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

GNU ld's internal linker scripts for RISC-V place .sdata and .sbss close.
This makes GP relaxation more profitable.

While here, when .sbss is present, set `__bss_start` to the start of
.sbss instead of .bss, to match GNU ld.

Note: GNU ld's internal linker scripts have symbol assignments and input
section descriptions which are not relevant for modern systems. We only
add things that make sense.

Reviewed By: craig.topper

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

  LWG3358 §[span.cons] is mistaken that to_address can throw

Since last - first has to throw tests are added to make sure this always
happens.

Depends on D142808

Reviewed By: #libc, ldionne

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

  LWG3839 range_formatter's set_separator, set_brackets, and
  underlying functions should be noexcept

Adds tests for:

  template<ranges::input_range R, class charT>
     struct range-default-formatter<range_format::sequence, R, charT>

These were missing, the format functions tests for the sequences
are already present.

Reviewed By: #libc, ldionne

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

Reviewed By: lntue

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

Also, an "arm" subfolder for baremetal config has been added.

Reviewed By: lntue

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

  LWG3881 Incorrect formatting of container adapters backed by std::string

Reviewed By: #libc, ldionne

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

Reviewed By: lntue

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

This prevents the test from failing when the default target doesn't
support the .warning directive.

Avoids using operator& in basic_string since an evil char-like type can
hijack this operator. Added some more evil operators, this found a place
where equality was compared directly and not via the traits.

This adds a helper test string. This is now only used in a few tests,
but the intention is to use this in more tests for basic_string.

Reviewed By: #libc, ldionne

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

The m type in a range formatter may only be used when a pair or a tuple
with two elements is used. This was not correctly validated as reported
in llvm.org/PR60995.

Reviewed By: ldionne, #libc

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

Fixes llvm.org/PR58714 reported by @jwakely and a similar issue
reported privately by @vitaut.

Reviewed By: ldionne, #libc

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

Fix affine analysis check for ops with no common block in their affine
scope. Clean up some out of date comments and naming.

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

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

The `REVERSE` keyword is described here:

https://sourceware.org/bugzilla/show_bug.cgi?id=27565

It complements `SORT` by allowing the order of input sections to be reversed.

This is particularly useful for order-dependent sections such as .init_array,
where `REVERSE` can be used to either detect static initialization order fiasco
issues or as a mechanism to maintain .ctors element order while transitioning to
the modern .init_array. Such a transition is described here:

https://discourse.llvm.org/t/is-it-possible-to-manually-specify-init-array-order/68649

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

Implements HLFIR lowering for %im and %re.

Reviewed By: jeanPerier

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

We can form a MU TU operation and remove the merge if they use the
same merge value.

My primary interest was a case involving VP intrinsics from our downstream,
but it requires another optimization that isn't in upstream yet. So I've used
RVV intrinsics to get the desired instructions.

Co-authored-by: Nitin John Raj <nitin.raj@sifive.com>

Reviewed By: fakepaper56

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

This results in expressions that appear in default function argument not
being checked for being actual constant expressions.
This aligns clang's behavior with the standard and fixes one of the
examples from https://wg21.link/P1073R3.

Reviewed By: shafik, cor3ntin

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

Add a set of `-Xmicrosoft` flags to control the Windows SDK and VisualC
tools directories.  This allows control over the selection of the SDK
and tools when using the GNU driver.

Differential Revision: https://reviews.llvm.org/D145007
Reviewed By: mstorjo

https://wg21.link/p1937 proposes that in unevaluated contexts, consteval
functions should not be immediately evaluated.
Clang implemented p1937 a while ago, its behavior is correct and the
test needs an update.

Reviewed By: aaron.ballman, shafik

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

Fixes #61160

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

GNU line marker directives are not recognised when preprocessing
assembly files, meaning they can't be used in the predefines file
meaning macros defined on the command line are reported as being
built-in.

Change this to permit line markers but only in the predefines file,
so we can correctly report command line macros as coming from the
command line.

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

At the moment, proveNoWrapViaConstantRanges is only used when creating
SCEV[Zero,Sign]ExtendExprs. We can get significant improvements by
strengthening flags after creating the AddRec.

I'll also share a follow-up patch that removes the code to strengthen
flags when creating SCEV[Zero,Sign]ExtendExprs. Modifying AddRecs while
creating those can lead to surprising changes.

Compile-time looks neutral:
https://llvm-compile-time-tracker.com/compare.php?from=94676cf8a13c511a9acfc24ed53c98964a87bde3&to=aced434e8b103109104882776824c4136c90030d&stat=instructions:u

Reviewed By: mkazantsev, nikic

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

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

Converting tosa.reshape to tensor.expand_shape and
tensor.collapse_shape logically belongs in the tosa-to-tensor
conversion process. In addition, we (rocMLIR downstream) want to use
the reshape -> expand/collapse_shape logic to simplify parts of our
Tosa integration without using the full tosa-to-linalg flow, further
motivating moving these patterns.

The downside to this change is that it means you need to run
tosa-to-tensor after tosa-to-linalg, which is probably a breaking
change.

Reviewed By: rsuderman

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

https://reviews.llvm.org/D130791 added an improvement that in case array
element has a trivial constructor, it is evaluated once and the result is
re-used for remaining elements. Make sure the constructor is evaluated
for single-elements arrays too.

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

Reviewed By: aaron.ballman

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

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

With suitable BooleanContent handling we could move this to TargetLowering::expandIntMINMAX, but this is good enough for X86

Fixes #61225

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

This patch adds the builtin type __SVCount_t to Clang, which is an opaque
scalable type defined in the SME2 C and C++ Language Extensions.

The type maps to the `target("aarch64.svcount")` LLVM IR type.

Reviewed By: paulwalker-arm

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