These warnings were introduced by D146561.

Reviewed By: aartbik, Peiming

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

Originally added in D128465. Used by `llvm:Support` and `lld:ELF`.

Enabled by default. Disable with `--@llvm_zstd//:llvm_enable_zstd=false`.

Reviewed By: MaskRay, GMNGeoffrey

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

[CSSPGO][Preinliner] Trim cold call edges of the profiled call graph for a more stable profile generation.

I've noticed that for some services CSSPGO profile is less stable than non-CS AutoFDO profile from profiling to profiling without source changes. This is manifested by comparing profile similarities. For example in my experiments, AutoFDO profiles are always 99+% similar over same binary but different inputs (very close dynamic traffics) while CSSPGO profile similarity is around 90%.

The main source of the profile stability is the top-down order computed on the profiled call graph in the llvm-profgen CS preinliner. The top-down order is used to guide the CS preinliner to pre-compute an inline decision that is later on fulfilled by the compiler. A subtle change in the top-down order from run to run could cause a different inline decision computed. A deeper look in the diversion of the top-down order revealed that:
	- The topological sorting inside one SCC isn't quite right. This is fixed by {D130717}.
	- The profiled call graphs of the two sides of the A/B run isn't 100% the same. The call edges in the two runs do not subsume each other, and edges appear in both graphs may not have exactly the same weight. This is due to the nature that the graphs are dynamic. However, I saw that the graphs can be made more close by removing the cold edges from them and this bumped up the CSSPGO profile stableness to the same level of the AutoFDO profile.

Removing cold call edges from the dynamic call graph may have an impact on cold inlining, but so far I haven't seen any performance issues since the CS preinliner mainly targets hot callsites, and cold inlining can always be done by the compiler CGSCC inliner.

Also fixing an issue where the largest weight instead of the accumulated weight for a call edge is used in the profiled call graph.

Reviewed By: wenlei

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

Support universal Mach-O binaries with a fat64 header. After
4d683f7f, dsymutil can now generate such binaries when the offsets
would otherwise overflow the 32-bit offsets in the regular fat header.

rdar://107289570

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

Change target feature of __builtin_amdgcn_global_atomic_fadd_f32
to atomic-fadd-rtn-insts. Enable atomic-fadd-rtn-insts for gfx90a,
gfx940 and gfx1100 as they all support the return variant of
`global_atomic_add_f32`.

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

Reviewed By: rampitec

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

Reviewed By: GMNGeoffrey

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

Reviewed By: aartbik

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

The scan-build tool assists various build systems with applying the Clang
static analyzer alongside compilation. It offers explicit integration with
Xcode's native build system aka `xcodebuild`; in this case it doesn't
substitute the compiler, but instead kindly asks xcodebuild to enable
the static analyzer, something that it already knows how to do.

Make sure scan-build's `-analyzer-config` flag (which translates to a
similar `clang -cc1 -analyzer-config` flag) is properly translated
to Xcode build system. This unbreaks a few related features such as
checker silencing.

No LIT tests because they'd require an Xcode installation on your system.

CopyFileToErr() uses Printf("%s", ...) which fails with a negative size on
files >2Gb (Its path is through var-args wrappers to an unnecessary "%s"
expansion and subject to int overflows) Using puts() in place of printf()
bypasses this path and writes the string directly to stderr. This avoids the
present loss of data when a crashed worker has generated >2Gb of output.

rdar://99384640

Reviewed By: yln, rsundahl

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

POWER Darwin support in the backend has been removed for some time: https://discourse.llvm.org/t/rfc-remove-darwin-support-from-power-backends
but Clang still has the TargetInfo and other remnants lying around.

This patch does some cleanup and removes those and other related frontend support still remaining. We adjust any tests using the triple to either remove
the test if unneeded or switch to another Power triple.

Reviewed By: MaskRay, nemanjai

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

The test is not applicable because HWASan does not intercept __tls_get_addr.

This is pre-emptive cleanup, to get ready for Kirill's patch to enable sanitizer common tests for HWASan (https://reviews.llvm.org/D147067).

Note that there is an outstanding dynamic TLS bug for sanitizers - https://github.com/google/sanitizers/issues/1409
- but that isn't applicable here due to the lack of interception.

Test: LIT_FILTER=resize_tls_dynamic ninja check-sanitizer

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

the v4 rebuilding is a best-effort because it's not possible to reliably
parse the DWO ID as it requires the abbrev section (& if the index isn't
trustworthy then there's no way to find the associated abbrev section
contribution for a given info section contribution)

But in v5 the DWO ID/type signature is in the header and can be rebuilt
losslessly (only at the cost of performance of rescanning/parsing the
headers of all the units), so let's implement that.

the testing isn't /ideal/ - I think the testing should've been
implemented as a hardcoded dwp file with a corrupted/incorrect index,
then the test could've demonstrated that reparsing the index produces
the right answer - but this is a quick port of the existing v5 test back
to v4 so that we don't lose coverage on the v4 codepath now that it's
separated from the v5 codepath.

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

[clang-tidy] Add option to ignore capture default by reference in cppcoreguidelines-avoid-capture-default-when-capturing-this

The rule exists primarily for when using capture default
by copy "[=]", since member variables will be captured by
reference, which is against developer expectations.

However when the capture default is by reference, then there
is no doubt: everything will be captured by reference. Add
an option to allow just that.

Note: Release Notes do not need update since this check
has been introduced in the current WIP release.

A ticket has been opened at the C++ Core Guidelines repo
to consider updating the rule such that this behavior
is the default one:
https://github.com/isocpp/CppCoreGuidelines/issues/2060

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

This isn't an ideal test - probably would be better if it had a
corrupted index (& was hardcoded - so it didn't depend on llvm-dwp) to
demonstrate that index rebuilding produces a distinct result.

But, ah well, this'll do for now.

Also, handle imaginary numbers, i.e., those with suffixes starting
with an 'i'.

Fixes #61676.

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

Per Fortran 2018, "NAN" and "NAN()" are to be translated into quiet
NaNs, and the other forms are implementation-dependent;  I've made
them quiet NaNs too.  Also process signs on input NaNs, which seems
wrong but other compilers all do it, and fix some misleading template
argument names noticed along the way.

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

FailureOr was used without including correct headers, so the code only works if the user of Transform.h includes the correct headers first.

Reviewed By: jyknight

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

The GPU support for the `libc` generates all its own headers. Since
these headers use the same names as the system headers we need to make
sure that they are separate. Currently, we either use the system headers
on the GPU or the GPU headers on the system. This patch makes them
explicitly separate. A follow-up patch will then make `clang` look in
this folder by default.

Reviewed By: sivachandra, lntue

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

In a now-reverted series of patches, I inadvertently broke the ability
for lldb-server to explain a crash reason. To ensure that this feature
continues to work after future refactors, let's test the feature.

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

Don't check ranks when a pointer actual argument is associated with
a pointer assumed-rank dummy argument.

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

We already use the `amdgpu-arch` and `nvptx-arch` tools to determine the
GPU architectures the user's system supports. We can provide
`LIBC_GPU_ARCHITECTURES=native` to allow users to easily build support
for only the one found on their system. This also cleans up the code
somewhat.

Reviewed By: tra

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

This is a preliminary change to make way for converting the Merger's identifier types from mere typedefs to actual types (which causes some issues that this patch fixes).

Depends On D146676

Reviewed By: aartbik

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

`Function.RawBranchCount` is initialized for fdata profile but not for yaml one.
The diff adds the computation of the field for yaml profiles

Reviewed By: Amir

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

Flang was missing value normalization for logical<->integer conversions
which is required by Flang specification. The shrinking logical<->logical
conversions were also incorrectly truncating the input.
This change performs value normalization for all logical<->integer
conversions and logical<->logical conversions between different kinds.

Note that value normalization is not strictly required for
logical(kind=k1)->logical(kind=k2) conversions when k1 < k2.

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

Missed the default return component of the function on original
implementation, which is a warning that causes subsequent
failure (but regardless it's incorrect behaviour and should
have been fixed).

Currently the cost for fshl is an overestimate causing SLP to vectorize when it is not necessary.

Reviewed By: fhahn

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

Many uses of getIntPtrType() were using that type to calculate the
neened type for GEP offset arguments. However, some time ago,
DataLayout was extended to support pointers where the size of the
pointer is not equal to the size of the values used to index it.

Much code was already migrated to, for example, use getIndexSizeInBits
instead of getPtrSizeInBits, but some rewrites still used
getIntPtrType() to get the type for GEP offsets.

This commit changes uses of getIntPtrType() to getIndexType() where
they are involved in a GEP-related calculation.

In at least one case (bounds check insertion) this resolves a compiler
crash that the new test added here would previously trigger.

This commit does not impact
- C library-related rewriting (memcpy()), which are operating under
the assumption that intptr_t == size_t. While all the mechanisms for
breaking this assumption now exist, doing so is outside the scope of
this commit.
- Code generation ...

Fixes printing of spaces in cases where the following are true:

  1. Persistent results are disabled
  2. The type has a summary string

As reported by @jgorbe in D146783, two spaces were being printed before the summary
string, and no spaces were printed after.

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

The affine loop utility `tilePerfectlyNestedLoops` was checking for the
validity of tiling as well as performing the tiling. This is
inconsistent with how other similar utilities work. Move out the
analysis/check from the utility so that the latter only performs the
mechanics of IR manipulation.

This is NFC/pure move beyond the change in behavior of
tilePerfectlyNestedLoops.

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

LLJIT needs access to symbols (e.g. llvm_orc_registerEHFrameSectionWrapper)
that will be defined in the executable when LLVM is linked statically.

This change is consistent with how other tools within LLVM use LLJIT. It
is required to make sure that `mlir-cpu-runner --host-supports-jit`
correctly returns `true` on platforms that do support JITting (in my
case that's AArch64 Linux).

See https://github.com/llvm/llvm-project/issues/61712 for more context.

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

FEAT_ATS1A adds three new AT system instruction aliases. This feature is
optional from v8.9a/v9.4a. FEAT_ATS1A is a very late addition to the
2022 A-profile VMSA extension, and has not yet been added to the public
docs available on developer.arm.com

These AT instructions are added without a command-line flag or feature,
because it is system-instruction only, and FEAT_S1PIE also has no
command-line flag.

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