This paper adds 'i' and 'j' as suffixes for forming a _Complex constant.
This feature has been supported in Clang since at least Clang 3.0, so
only test coverage is needed.

It does remove -Wgnu-imaginary-constant in C mode (still used in C++
mode) because the feature is now a C2y feature rather than a GNU one.

… better formatting

When forcing emit zero, we need to skip terminators of a MBB; otherwise
the terminator list of the MBB would be broken.

…ions (llvm#112148)

Bug fix: `@autoreleasepool`, `@synchronized`, and `@finally` were not
being noticed and treated as function effect violations.

---------

Co-authored-by: Doug Wyatt <[email protected]>

The worker clause specifies iterations of the loop/ that are executed in
parallel by distributing the iterations among the multiple works within
a single gang.

The sema rules for this type are simply that it cannot be combined with
a `kernel` construct with a `num_workers` clause, child `loop` clauses
cannot contain a `gang` or `worker` clause, and that the argument is oly
allowed when associated with a `kernel`.

…as `constexpr`. (llvm#112129)

Closes llvm#107985.

LanguageExtensions.rst states that `__builtin_shufflevector` and
`__builtin_convertvector` can be evaluated as constants, but this is not
reflected in Butiltins.td. This patch aligns these two.

…llvm#112112)

Fixes: llvm#109385

…108931)

1. Propagate the nneg flag in WidenVecRes
2. Use SINT_TO_FP in expandUINT_TO_FP when possible.

Currently, our unwinder assumes that the functions are continuous (or at
least, that there are no functions which are "in the middle" of other
functions). Neither of these assumptions is true for functions optimized
by tools like propeller and (probably) bolt.

While there are many things that go wrong for these functions, the
biggest damage is caused by the unwind plan caching code, which
currently takes the maximalist extent of the function and assumes that
the unwind plan we get for that is going to be valid for all code inside
that range. If a part of the function has been moved into a "cold"
section, then the range of the function can be many megabytes, meaning
that any function within that range will probably fail to unwind.

We end up with this maximalist range because the unwinder asks for the
Function object for its range. This is only one of the strategies for
determining the range, but it is the first one -- and also the most
incorrect one. The second choice would is asking the eh_frame section
for the range of the function, and this one returns something reasonable
here (the address range of the current function fragment) -- which it
does because each fragment gets its own eh_frame entry (it has to,
because they have to be continuous).

With this in mind, this patch moves the eh_frame (and debug_frame) to
the front of the queue. I think that preferring this range makes sense
because eh_frame is one of the unwind plans that we return, and some
others (augmented eh_frame) are based on it. In theory this could break
some functions, where the debug info and eh_frame disagree on the extent
of the function (and eh_frame is the one who's wrong), but I don't know
of any such scenarios.

Check invoked tool with `starts_with`.

Addresses the issue where `perf2bolt` invoked using a distro symlink
`perf2bolt-16` fails to run in perf2bolt mode and runs in llvm-bolt mode
instead.

The issue is mentioned in https://vondra.me/posts/playing-with-bolt-and-postgres/

Test Plan:
```
ln -sf perf2bolt perf2bolt-20
perf2bolt-20 clang -p perf.data -o fdata.clang -w yaml.clang
...
PERF2BOLT: wrote 188593 objects and 0 memory objects to fdata.clang
```

Reviewers: ayermolo, rafaelauler, dcci, maksfb

Reviewed By: maksfb

Pull Request: llvm#111072

…lvm#111659)

Refer: 7.3.1 from [ISO
SPEC](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)

I have added complex variants of F16 and F128 in libc doc but have
omitted support for them since we will have to first investigate how
their support matrix for clang and gcc looks like, and then add header
guards for them accordingly. Planning to add them in follow up PRs once
this gets landed.

…m#111332)

Currently, WebAssembly/WASI target does not provide direct support for
code coverage.
This patch set fixes several issues to unlock the feature. The main
changes are:

1. Port `compiler-rt/lib/profile` to WebAssembly/WASI.
2. Adjust profile metadata sections for Wasm object file format.
- [CodeGen] Emit `__llvm_covmap` and `__llvm_covfun` as custom sections
instead of data segments.
    - [lld] Align the interval space of custom sections at link time.
- [llvm-cov] Copy misaligned custom section data if the start address is
not aligned.
    - [llvm-cov] Read `__llvm_prf_names` from data segments
3. [clang] Link with profile runtime libraries if requested

See each commit message for more details and rationale.
This is part of the effort to add code coverage support in Wasm target
of Swift toolchain.

For the block smaller than a page size, one block is unlikely to
introduce more unused pages (at most 2 if it acrosses the page boundary
and both touched pages are unused). So it's better to apply the
threshold to reduce the time of scanning groups that can't release any
new pages.

Fix buildbot errors due to llvm#111659

Fixes llvm#83482

This adds support for these instructions and also tests getOperandInfo
for these instructions as well.

This adds support for these instructions and also tests getOperandInfo
for these instructions as well.

This is a copy of llvm#97402(with minor updates), which is now ready to land.

---------

Co-authored-by: Sergey Kozub <[email protected]>

This change is identical to
26800a2 ("[sanitizer] Undef
_TIME_BITS along with _FILE_OFFSET_BITS on Linux"), but for
sanitizer_procmaps_solaris.cpp.

Indeed, even though sanitizer_procmaps_solaris.cpp is Solaris
specific, it also gets built on Linux platforms. It also includes
sanitizer_platform.h, which also ends up including features-time64.h,
causing a build failure on 32-bit Linux platforms on which 64-bit
time_t is enabled by setting _TIME_BITS=64.

To fix this, we do the same change: undefine _TIME_BITS, which anyway
will cause no harm as the rest of this file is inside a
SANITIZER_SOLARIS compile-time conditional.

Fixes:

In file included from /home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features.h:394,
                 from ../../../../libsanitizer/sanitizer_common/sanitizer_platform.h:25,
                 from ../../../../libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp:14:
/home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is al
lowed only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
      |     ^~~~~

Signed-off-by: Thomas Petazzoni <[email protected]>
Closes: llvm#99699

This is a follow-up to llvm#108344.

The original bailout check was overly strict, causing it to miss cases
like the vector(initializer_list, allocator) constructor. This patch
relaxes the check to address that issue.

Fix llvm#111680

Ensures that struct padding is not skipped, as it may contain actual
data if the struct is really a union.

The patch originated from a discussion on llvm#53710

Fixes llvm#53710

…rective (llvm#112066)

Fixes llvm#87717.

It doesn't make a difference currently, but MTE globals are only
supported on Android, so that's the more natural target to use.

This addresses an issue introduced in llvm#112041.

…iption (llvm#112057)

When NewInterval is below DAGInterval we used to revisit instructions
already visited. This patch fixes this by separating the scan in two:
1. The full scan of the NewInterval, and
2. The cross-interval scan for DAGInterval.

This is further explained in the new description.

…12252)

Reverts llvm#112014

The change didn't update the iterator

If a pseudo has a passthru, I believe the first source operand will have
operand no 2, not 1.

Fixes llvm#110122
- Create remap_file_pages.h/.cpp wrapper for the linux sys call.
- Add UnitTests for remap_file_pages
- Add function to libc/spec/linux.td
- Add Function spec to mman.yaml

This reverts commit 4a0dc3e.
Breaks tests, see comments on
llvm#108802

…#112235)

CFPropertyListCreateXMLData has been deprecated since macOS 10.10. Use
CFPropertyListCreateData instead.

…2257)

After llvm#80007 Fuchsia builds are
now always building cxx_shared for arm64 and x64 Linux. Ultimately, this
is because the LIBCXX_ENABLE_SHARED is not used in compiler-rt to select
the correct libc++ target, and because cxx_shared is now always defined,
it is selected as a dependency when building runtimes tests.

---------

Co-authored-by: Petr Hosek <[email protected]>

…112275)

Fix `BUILD_SHARED_LIBS=ON` build for
d4efc3e

We usually override operand related fields in the class body instead
of at the top level.

…m#112254)

)

c.srli(64) and c.srai(64) are encoded differently than c.slli(64). The
former have a 3-bit register, while the latter has a 5-bit register.
c.srli and c.srai already use RVInst16CB.

The "let Inst{11-10} =" prevented this from causing any functional
issues by dropping the upper 2 bits of the register. The ins/outs list
uses GPRC so the register class is constrained.

…1409)"

This reverts commit a89e016.

This is being reverted because it broke the test:

Unwind/trap_frame_sym_ctx.test

/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test:21:10: error: CHECK: expected string not found in input
 CHECK: frame #2: {{.*}}`main

As discussed in llvm#109284
Copied msan tests from 64-bit platforms to following 32-bit platforms:
* MIPS
* ARM
* RISCV
* PowerPC
* i386

Most of the tests have been copied form mips64.
Target triple and test contents have not been changed: to be done in
next PR.

---------

Co-authored-by: Kamil Kashapov <[email protected]>

Fixes the following error:
```
clang-tools-extra/docs/ReleaseNotes.rst:247: WARNING: unknown document: 'clang-tidy/checks/readability/readability-identifier-naming' [ref.doc]
```

This patch implements the UnscheduledSuccs counter in DGNode. It counts
the number of unscheduled successors and is used by the scheduler to
determine when a node is ready.

)

This allows IDEs to render LLDB expression diagnostics to their liking
without relying on characterprecise ASCII art from LLDB. It is exposed
as a versioned SBStructuredData object, since it is expected that this
may need to be tweaked based on actual usage.

…s in C" (llvm#109898) (llvm#110051)

This reverts commit d50eaac. Also fixes
a bug calculating offsets for bit fields in the original patch.

…lvm#112282)

…es (llvm#112048)

/llvm-project/llvm/include/llvm/Transforms/Vectorize/SandboxVectorizer/DependencyGraph.h:231:10:
error: unused variable 'Inserted' [-Werror,-Wunused-variable]
    auto Inserted = MemPreds.insert(PredN).second;
         ^
1 error generated.

Update the TestCTF Makefile to remove the DWARF 5 sections.

…lvm#112260)

Remove support for ASL (Apple System Log) which has been deprecated
since macOS 10.12. Fixes the following warnings:

warning: 'asl_new' is deprecated: first deprecated in macOS 10.12 -
os_log(3) has replaced asl(3)
warning: 'asl_set' is deprecated: first deprecated in macOS 10.12 -
os_log(3) has replaced asl(3)
warning: 'asl_vlog' is deprecated: first deprecated in macOS 10.12 -
os_log(3) has replaced asl(3)

…/u> 2/1` (llvm#111284)` (llvm#111998)

Relands llvm#111284. Test failure with stage2 build has been fixed by
llvm#111946.


Some targets have better codegen for `ctpop(X) u< 2` than `ctpop(X) ==
1`. After llvm#100899, we set the
range of ctpop's return value to indicate the argument/result is
non-zero.

This patch converts `ctpop(X) ==/!= 1` into `ctpop(X) u</u> 2/1` in CGP
to fix llvm#95255.

…lvm#111977)

This commit essentially reverts https://reviews.llvm.org/D30453.

In llvm#109961, objcopy util search code was added to dotest.py. dotest.py
should use llvm-X by default if no path to a utility X is provided
externally.

However, it doesn't work out for llvm-objcopy, since objcopy path is
always overridden with the lines being removed here. It causes a problem
with cross-platform testing when objcopy used by cmake doesn't support
targets/executable file formats other than native.

I suppose these lines are unnecessary after llvm#109961, so they can be
safely removed.

This revision adds hyperbolic trigonometric sinh, cosh, and tanh
intrinsic ops.

…112242)

…aced init (llvm#109505)"

This reverts commit 98281da which caused a
regression.

Fixes llvm#112176.

…111967)

- V_SET_INACTIVE is always in WWM/WQM so can be treated like any other
operation in WWM/WQM.
- After encountering SI_SPILL_S32_TO_VGPR loop should bypass to avoid
double processing its defs.

Windows NT/MIPS and Windows CE/MIPS always used COFF format.

This is an extract of PR llvm#107744.

Add the MIPS COFF relocation types. They will be needed to add support
for MIPS Windows object file.

This is an extract of PR
llvm#107744.

The spec refers to the field as rd'/rs1' so we might as well name the
destination rd.

The operation will be used in the CUF constructor to register the kernel
functions. This allow to delay this until codegen when the gpu.binary
will be available.

Reverts llvm#112268

…d sf.v.xvw instructions (llvm#111630)

The instruction has the constraint, but the pseudo instruction is
missing.

…#112291)

This is an assembly only alias for c.nop.

…112252) (llvm#112266)

This reverts commit 037938d.

Fixed the iterator to avoid infinite loop

…ers (llvm#112177)

When parsing its function parameters, we don't change the CurContext to
the lambda's function declaration. However,
CheckIfAnyEnclosingLambdasMustCaptureAnyPotentialCaptures() has not
yet adapted to such behavior when nested lambdas come into play.
Consider the following case,

    struct Foo {};

    template <int, Foo f> struct Arr {};

    constexpr void foo() {
      constexpr Foo F;
      [&]<int I>() {
         [&](Arr<I, F>) {};
       }.template operator()<42>();
    }

As per [basic.def.odr]p5.2, the use of F constitutes an ODR-use. And
per [basic.def.odr]p10, F should be ODR-usable in that interleaving
scope.

We failed to accept the case because the call to tryCaptureVariable()
in getStackIndexOfNearestEnclosingCaptureCapableLambda() suggested
that F is needlessly captureable. That was due to a missed handling
for AfterParameterList in FunctionScopeIndexToStopAt, where it still
presumed DC and LSI matched.

Fixes llvm#47400
Fixes llvm#90896

Fixes: llvm#110190

(reland with fixed sed command for macos)

Handle the `!callees` metadata to further reduce the amount of indirect
call cases that end up conservatively assuming that any indirectly
callable function is a potential target.

`APFloat::APFloat(const fltSemantics &Semantics, integerPart I)`
interprets 'I' as a unsigned integer.
Fix the bug found in
llvm#112113 (comment).

Use explicit target and stop restricting hosts it can run on.

…12238)

Comparing their PrimTypes isn't enough in this case. We can have a
floating cast here as well.

The [last attempt](llvm#89036) to
fix llvm#41441 has been reverted
immediately.

Here I'm trying the simplest idea I've been able to come with: skip
handling dependent case in `BuildCXXNew`.

The original test (borrowed form
llvm#89036) passes.

Also I've created and added to the tests a minimal repro of the code
llvm#89036 fails on. This
(obviously) also passes.

…112316)

Use const pointers for various `Init` objects. This is a part of effort
to have better const correctness in TableGen backends:


https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089

…terializations (llvm#112128)

This commit adds an optional `originalType` parameter to target
materialization functions. Without this parameter, target
materializations are underspecified.

Note: `originalType` is only needed for target materializations.
Source/argument materializations do not have it.

Consider the following example: Let's assume that a conversion pattern
"P1" replaced an SSA value "v1" (type "t1") with "v2" (type "t2"). Then
a different conversion pattern "P2" matches an op that has "v1" as an
operand. Let's furthermore assume that "P2" determines that the
legalized type of "t1" is "t3", which may be different from "t2". In
this example, the target materialization callback will be invoked with:
outputType = "t3", inputs = "v2", originalType = "t1". Note that the
original type "t1" cannot be recovered from just "t3" and "v2"; that's
why the `originalType` parameter is added.

This change is in preparation of merging the 1:1 and 1:N dialect
conversion drivers. As part of that change, argument materializations
will be removed (as they are no longer needed; they were just a
workaround because of missing 1:N support in the dialect conversion).
The new `originalType` parameter is needed when lowering MemRef to LLVM.
During that lowering, MemRef function block arguments are replaced with
the elements that make up a MemRef descriptor. The type converter is set
up in such a way that the legalized type of a MemRef type is an
`!llvm.struct` that represents the MemRef descriptor. When the bare
pointer calling convention is enabled, the function block arguments
consist of just an LLVM pointer. In such a case, a target
materialization will be invoked to construct a MemRef descriptor (output
type = `!llvm.struct<...>`) from just the bare pointer (inputs =
`!llvm.ptr`). The original MemRef type is required to construct the
MemRef descriptor, as static sizes/strides/offset cannot be inferred
from just the bare pointer.

Add an additional adaptor constructor that copies everything except for
the values. The values are provided with by a second parameter.

This commit is in preparation of merging the 1:1 and 1:N dialect
conversions. As part of that, a new `matchAndRewrite` function is added.
For details, see this RFC:
https://discourse.llvm.org/t/rfc-merging-1-1-and-1-n-dialect-conversions/82513

```c++
template <typename SourceOp>
class OpConversionPattern : public ConversionPattern {
 public:
  using OneToNOpAdaptor =
      typename SourceOp::template GenericAdaptor<ArrayRef<ArrayRef<Value>>>;

  virtual LogicalResult
  matchAndRewrite(SourceOp op, OneToNOpAdaptor adaptor,
                  ConversionPatternRewriter &rewriter) const {
    SmallVector<Value> oneToOneOperands =
        getOneToOneAdaptorOperands(adaptor.getOperands());

    // This OpAdaptor constructor is added by this commit.
    return matchAndRewrite(op, OpAdaptor(oneToOneOperands, adaptor), rewriter);
  }
};
```

…vm#112172)

This adds computeKnownBits support for vector->vector G_UNMERGE_VALUES,
grabbing the known bits with an adjusted DemandedElts mask.

This makes sure that APInt::getAllOnes() keeps working after the APInt
constructor assertions are enabled.

I'm relaxing the requirement for the signed case to either an all zeros
or all ones integer. This is basically saying that we can interpret the
zero-width integer as either positive or negative.

This fixes a problem introduced in llvm#80094. That PR copied negative
features from the TargetMachine to the end of the feature string. This
is not correct, because even if we have a baseline TM of say `-simd128`,
but a function with `+simd128`, the coalesced feature string should have
`+simd128`, not `-simd128`.

To address the original motivation of that PR, we should instead
explicitly materialize the negative features in the target feature
string, so that explicitly disabled default features are honored.

Unfortunately, there doesn't seem to be any way to actually test this
using llc, because `-mattr` appends the specified features to the end of
the `"target-features"` attribute. I've tested this locally by making it
prepend the features instead.

9ad72df added split of _BitInt
constants when required. Before folding back, check that the constant
exists.

Implementation of `computeCost()` function for `VPReductionRecipe`.

Note that `in-loop` and `any-of` reductions are not supported by
VPlan-based cost model currently.

When investigating PR llvm#101634, it turned out that
`UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp`
isn't Linux-specific at all. In fact, none of the
`ubsan/TestCases/Misc/Linux` tests are.

Therefore this patch moves them to `Misc/Posix` instead.

Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`,
`x86_64-pc-linux-gnu`, and `amd64-pc-solaris2.11`.

When testing on Linux/sparc64 with a `runtimes` build, the
`UBSan-Standalone-sparc :: TestCases/Misc/Linux/sigaction.cpp` test
`FAIL`s:
```
runtimes/runtimes-bins/compiler-rt/test/ubsan/Standalone-sparc/TestCases/Misc/Linux/Output/sigaction.cpp.tmp: error while loading shared libraries: libclang_rt.ubsan_standalone.so: wrong ELF class: ELFCLASS64
```
It turns out SPARC needs the same `LD_LIBRARY_PATH` handling as x86.

This is what this patch does, at the same time noticing that the current
duplication between `lit.common.cfg.py` and
`asan/Unit/lit.site.cfg.py.in` isn't necessary.

Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.

This PR would fix llvm#16855 .

The correct lookup to use for class names is Tag name lookup,
because it does not take namespaces into account. The lookup before
does and because of this some valid programs are not accepted.

An example scenario of a valid program being declined is when you have a struct (let's call it `y`) inheriting from another struct with a name `x` but the struct `y` is in a namespace that is also called `x`:
```
struct x
{};

namespace
{
    namespace x
    {
        struct y : x
        {};
    }
}
```

This shall be accepted because: 
```
C++ [class.derived]p2 (wrt lookup in a base-specifier): The lookup for
  // the component name of the type-name or simple-template-id is type-only.
```

Inspired by
https://discourse.llvm.org/t/rfc-signedness-independent-icmps/81423

Some typos are also fixed. Address
llvm#112067 (review).

Write dedicated tests for foldSelectValueEquivalence, demonstrating that
it does not perform many GVN-like replacements when:

- the comparison is a vector-type
- the comparison is a floating-point type

 as a prelude to fixing these deficiencies.

LDV could reorder reinserted fragment and non-fragment debug values for
the same variable (compared to the input order), potentially resulting
in stale values being presented.

For example, before:

  DBG_VALUE 1001, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 0, 16)
  DBG_VALUE 1002, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 16, 16)
  DBG_VALUE %0, $noreg, !13, !DIExpression()

After (without this patch):

  DBG_VALUE %stack.0, 0, !13, !DIExpression()
  DBG_VALUE 1002, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 16, 16)
  DBG_VALUE 1001, $noreg, !13, !DIExpression(DW_OP_LLVM_fragment, 0, 16)

It would also reorder DBG_VALUEs for different variables. Although that
does not matter for the debug information output, it resulted in some
noise in before/after pass diffs.

This should hopefully align so that instruction referencing and
DBG_VALUE emit debug instructions in the same order (see the
sdag-salvage-add.ll change).

…to scalar Constant{Int,FP}. (llvm#111005)

This fixes a failure path when the use-constant-##-for-###-splat IR
options are enabled.

foldSelectEquivalence currently doesn't support GVN-like replacements on
vector types. Put in the checks for potentially lane-crossing
operations, and lift the limitation.

…inked with libc++ statically (llvm#98694)

This is to fix buildbot failure
https://lab.llvm.org/staging/#/builders/195/builds/4255.

The test expects 'libstdc++' or 'libc++' SO module in the module list.
In case when static linking with libc++ is on by default, none of them
may be present.

Thus, USE_SYSTEM_STDLIB is added to ensure the presence of any of them.

---------

Co-authored-by: Vladimir Vereschaka <[email protected]>