Created using spr 1.3.5-bogner

It is possible for a compiler to support the warning without being able
to compile `export module foo;`, so use that in addition to the warning
to check whether C++20 modules are supported.

When an uninstrumented libatomic is used with a TSan instrumented
memcpy, TSan may report a data race in circumstances where writes are
arguably safe.

This occurs because __atomic_compare_exchange won't be instrumented in
an uninstrumented libatomic, so TSan doesn't know that the subsequent
memcpy is race-free.

On the other hand, pthread_mutex_(un)lock will be intercepted by TSan,
meaning an uninstrumented libatomic will not report this false-positive.

pthread_mutexes also may try a number of different strategies to acquire
the lock, which may bound the amount of time a thread has to wait for a
lock during contention.

While pthread_mutex_lock has a larger overhead (due to the function
call and some dispatching), a dispatch to libatomic already predicates
a lack of performance guarantees.

The frontend computes the necessary alignment for COMMON blocks but this
information is never carried over to the code generation and can lead to
segfault for COMMON block that requires a non default alignment.

This patch add an optional attribute on fir.global and carries over the
information.

Adds a split-dwarf test for DWARF5 with multiple CUs.

Before C++23, we would check a constexpr function body to diagnose if
the function can never be evaluated in a constant expression context.
This was previously required standards behavior, but C++23 relaxed the
restrictions with P2448R2. While this checking is useful, it is also
quite expensive, especially in pathological cases (see #92924 for an
example), because it means the mere presence of a constexpr function
definition will require constant evaluation even if the function is not
used within the TU.

Clang suppresses diagnostics in system headers by default and system
headers (like STL implementations) can be full of constexpr function
bodies. Now we suppress the check for a diagnostic if the function
definition is in a system header or if the `-Winvalid-constexpr`
diagnostic is disabled. This should have some mild compile time
performance improvements.

Also, the previous implementation would disable the diagnostic in C++23
mode entirely. Due to the benefit of the check, this patch now makes it
possible to enable the diagnostic explicitly in C++23 mode.

We received a bug report where someone was trying to print a global
variable without a process. This would succeed in a debug build but fail
in a on optimized build. We traced the issue back to the location being
described by a DW_OP_addr + DW_OP_piece.

The issue is that the DWARF expression evaluator only support reading
pieces from a load address. There's no reason it cannot do the same for
a file address, and indeed, that solves the problem.

I unsuccessfully tried to craft a test case to illustrate the original
example, using a global struct and trying to trick the compiler into
breaking it apart with SROA. Instead I wrote a unit test that uses a
mock target to read memory from.

rdar://127435923

All of these instructions can be generated using regular LL intrinsics.

Specified at:

https://github.com/WebAssembly/half-precision/blob/29a9b9462c9285d4ccc1a5dc39214ddfd1892658/proposals/half-precision/Overview.md

## Consistent PDB GUID in `llvm-readobj`

Currently, the PDB GUID is shown as a byte array:
`PDBGUID: (D8 4C 88 D9 26 15 1F 11 4C 4C 44 20 50 44 42 2E)`

This is inconsistent with `llvm-pdbutil` (e.g. `llvm-pdbutil dump
--summary`) which shows it as a hexadecimal string.
Additionally, `yaml2obj` uses the same hexadecimal string format.

In general, the hexadecimal string is the common representation for PDB
GUIDs on Windows.

This PR changes it to be consistent as shown below:
`PDBGUID: {D9884CD8-1526-111F-4C4C-44205044422E}`

Make sure we count the anonymous union as an initialized field, so we
properly construct the AST.

Included bonus testcase Test3, which shows a remaining gap: an anonymous
union can contain a partially initialized anonymous struct, and we
handle that inconsistently.

Fixes #91257

Simplify by setting PseudoInstr to the tablegen name of the Pseudo in
the first place.

This will allow scanner clients to be able to compute e.g. auto-linking
dependencies of the scanned translation unit.

`findOrphanPos` finds the most similar output section (that has input
sections). In the event of proximity ties, we select the first section.

However, when an orphan section's rank is equal to or larger than the
most similar sections's, it makes sense to prioritize the last similar
section. This new behavior matches GNU ld better.

```
// orphan placement for .bss (SHF_ALLOC|SHF_WRITE, SHT_NOBITS)

WA SHT_PROGBITS
(old behavior) <= here
A
WA SHT_PROGBITS
AX
WA (.data)
(new behavior) <= here
```

When the orphan section's rank is less, the current behavior
prioritizing the first section still makes sense.
```
// orphan with a smaller rank, e.g. .rodata

<= here
WA
AX
WA
```

Close #92987

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

flang/test/Semantics/call40.f90 was failing on Darwin:
actual at 27: VAL or REF are not allowed for dummy argument 'a='
  that must be passed by means of a descriptor
expect at 27: %VAL or %REF are not allowed for dummy argument 'a='
  that must be passed by means of a descriptor

When messages.Say() is called with more arguments than just the
fixed text message, the message is treated as a format string,
passed to vsnprintf. Therefore, the '%' chars in it must be
escaped.

Note that no conversion happens when there is only a fixed text
message. Escaping '%' in this case causes "%%" to be outputted.
This can be confusing for someone expecting printf-like behavior.
Processing these text messages with snprintf could solve this,
as a future improvement.

We see some tests are failing internally after 12949c95.

In some CAS systems, we might not see the exact binary name (clang),
this patch adds the `-no-canonical-prefixes` option to the command line to not
realpath-ify the binary name.

See the following example:
```
define i1 @src(i64 %x, i1 %y) {
  %1526 = icmp ne i64 %x, 0
  %1527 = icmp eq i64 %x, 0
  %sel = select i1 %y, i1 %1526, i1 %1527
  ret i1 %sel
}

define i1 @tgt(i64 %x, i1 %y) {
  %1527 = icmp eq i64 %x, 0
  %sel = xor i1 %y, %1527
  ret i1 %sel
}
```
I find that this pattern is common in C/C++/Rust code base.
This patch folds `select Cond, Y, X` into `Cond ^ X` iff:
1. X has the same type as Cond
2. X is poison -> Y is poison
3. X == !Y

Alive2: https://alive2.llvm.org/ce/z/hSmkHS

With MLIR inlining (e.g. `flang-new -mmlir -inline-all=true`)
the current TBAA tags attachment is suboptimal, because
we may lose information about the callee's dummy arguments
(by bypassing fir.declare in AliasAnalysis::getSource).
This is a conservative first step to improve the situation.
This patch makes AddAliasTagsPass to account for fir.dummy_scope
hierarchy after MLIR inlining and use it to place the TBAA tags
into TBAA trees corresponding to different function scopes.
The pass uses special mode of AliasAnalysis to find the instantiation
point of a Fortran variable (a [hl]fir.decalre) when searching
for the source of a memory reference. In this mode, AliasAnalysis
will always stop at fir.declare operations that have dummy_scope
operands - there should not be a reason to past throught it
for the purpose of TBAA tags attachment.

Any of the `zext` bits in a `zext nneg` can be converted to `sext` but
when checking if casts are compatible `BasicAA` fails to take into
account `nneg`. This change adds tracking of `nneg` to the `CastedValue`
struct and ensures that `sext` and `zext` bits are treated as
interchangeable when either `CastedValue` has a `nneg`. When
distributing casted values in `GetLinearExpression` we conservatively
discard the `nneg` from the `CastedValue`, except in the case of `shl
nsw`, where we know the sign has not changed to negative.

Allows to simplify the definition itself.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

To avoid generating unnecessary values, we don't create a new value but
instead
leave it to the specific analysis to do this if desired.

- The first hidden-helper-thread did not trigger thread-begin
- The "detaching" from a target-task when waiting for completion missed
to call task-switch
- Target tasks identified themself as explicit task

Co-authored-by: Kaloyan Ignatov <kaloyan.ignatov@rwth-aachen.de>

Implement emitPrologue/emitEpilogue methods, determine/spill/restore
callee saved registers functionality with test. Also implement lowering
of the DYNAMIC_STACKALLOC/STACKSAVE/STACKRESTORE stack operations with
tests.

In older versions there is this problem:

https://developercommunity.visualstudio.com/t/c-shared-state-futuresstate-default-constructs-the/60897

Which prevents us making a future out of a result type. There's
no good workaround so just don't compile this for older versions.

goma is deprecated and not maintained anymore.

Nothing in the standard actually prevents TARGET from being an
assumed-rank if the POINTER is. The only rank related constraints says:
"POINTER is not assumed-rank, TARGET shall have the same rank as
POINTER.".

This adds compare and branch instructions fusion for Neoverse V2.
According to the Software Optimization Guide:
Specific Aarch64 instruction pairs that can be fused are as follows: 
CMP/CMN (immediate) + B.cond
CMP/CMN (register) + B.cond

Performance for SPEC2017 is neutral, but another benchmark improves
significantly.
Results for SPEC2017 on a Neoverse V2:
500.perlbench 0%
502.gcc_r 0%
505.mcf_r -0.15%
523.xalancbmk_r -0.43%
525.x264_r 0%
531.deepsjeng_r 0%
541.leela_r -0.16%
557.xz_r -0.47%

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

Original commit message:"

[clang-repl] Extend the C support. (#89804)

The IdResolver chain is the main way for C to implement lookup rules.  Every new
partial translation unit caused clang to exit the top-most scope which in turn
cleaned up the IdResolver chain. That was not an issue for C++ because its
lookup is implemented on the level of declaration contexts.

This patch keeps the IdResolver chain across partial translation units
maintaining proper C-style lookup infrastructure.
"

It was reverted in dfdf1c5f because it broke the
bots of lldb. This failure was subtle to debug but the current model does not
work well with ObjectiveC support in lldb. This patch does cleans up the
partial translation units in ObjectiveC. In future if we want to support
ObjectiveC we need to understand what exactly lldb is doing when recovering from
errors...

The range may no longer be valid after the select has been
optimized away.

This fixes the kernel miscompiles reported at
https://github.com/ClangBuiltLinux/linux/issues/2031.

This patch covers the following Core issues:
[CWG1862](https://cplusplus.github.io/CWG/issues/1862.html) "Determining
“corresponding members” for friendship"
[CWG1918](https://cplusplus.github.io/CWG/issues/1918.html) "`friend`
templates with dependent scopes"
[CWG1945](https://cplusplus.github.io/CWG/issues/1945.html) "Friend
declarations naming members of class templates in non-templates"

All of them were resolved by CWG1862, where the current wording of
[[temp.friend] p5](https://eel.is/c++draft/temp.friend#5) comes from:
> A template friend declaration may declare a member of a dependent type
to be a friend[.](https://eel.is/c++draft/temp.friend#5.sentence-1) The
friend declaration shall declare a function or specify a type with an
[elaborated-type-specifier](https://eel.is/c++draft/dcl.type.elab#nt:elaborated-type-specifier),
in either case with a
[nested-name-specifier](https://eel.is/c++draft/expr.prim.id.qual#nt:nested-name-specifier)
ending with a
[simple-template-id](https://eel.is/c++draft/temp.names#nt:simple-template-id),
C, whose
[template-name](https://eel.is/c++draft/temp.names#nt:template-name)
names a class
template[.](https://eel.is/c++draft/temp.friend#5.sentence-2) The
template parameters of the template friend declaration shall be
deducible from C
([[temp.deduct.type]](https://eel.is/c++draft/temp.deduct.type))[.](https://eel.is/c++draft/temp.friend#5.sentence-3)
In this case, a member of a specialization S of the class template is a
friend of the class granting friendship if deduction of the template
parameters of C from S succeeds, and substituting the deduced template
arguments into the friend declaration produces a declaration that
corresponds to the member of the
specialization[.](https://eel.is/c++draft/temp.friend#5.sentence-4)

A useful example is provided after the paragraph:
https://eel.is/c++draft/temp.friend#example-4

.

Neither of Core issues is implemented, because we don't support
dependent nested friend specifiers.

---------

Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com>

When doing a runtimes build with LTO using ld.bfd (or ld.gold), the
build starts failing with ninja 1.12, which added a new critical path
scheduler. The reason is that LLVMgold.so is not available yet at the
point where runtimes start being build, leading to configuration
failures in the nested cmake invocation.

Fix this by adding an explicit dependency on LLVMgold.so if it is
available. (It may not always be necessary, e.g. if the used linker is
lld, but it would be hard to detect when exactly it may or may not be
needed, so always adding the dependency is safer.)

Pass variadic arguments without changing their type, unlike the fixed
ones.

Fixed arguments are modified to better fit into registers. This patch
leaves those unchanged.

Splitting struct types into individual fields and packing small structs
into integers works well for passing via registers. Variadic arguments
are currently unimplemented in the backend. They're likely to be
implemented as a pointer to stack memory in which case register-themed
optimisations are inapplicable.

Splitting the struct into fields makes it difficult to implement va_arg
robustly. The rules around padding and alignment to inverse the struct
splitting could be constructed, but at high complexity and no particular
advantage.

Passing types as-is means there is a 1:1 correspondence with the type
information va_arg has to work with and the parameter type at the call
site.

This is an ABI change, but as the only functions affected are variadic
ones which are presently a compilation error, not a functional break.
Factored out of the larger #93362 and can land independently.

Add overloads of GetElementPtrInst::Create() that accept
GEPNoWrapFlags, and switch the bool parameters in IRBuilder to
accept it instead as well.

As a sample use, switch GEP i8 canonicalization in InstCombine to
preserve the original flags.

Don't skip searching in `ToContext` during importing `EnumDecl`. And
`IsStructuralMatch` in `StructralEquivalence` can make sure to determine
whether the found result is match or not.

---------

Co-authored-by: huqizhi <836744285@qq.com>