[sanitizer] Intercept glibc 2.38 __isoc23_* functions

`strtol("0b1", 0, 0)` can be (pre-C23) 0 or (C23) 1.
`sscanf("0b10", "%i", &x)` is similar. glibc 2.38 introduced
`__isoc23_strtol` and `__isoc23_scanf` family functions for binary
compatibility.

When `_ISOC2X_SOURCE` is defined (implied by `_GNU_SOURCE`) or
`__STDC_VERSION__ > 201710L`, `__GLIBC_USE_ISOC2X` is defined to 1 and
these `__isoc23_*` symbols are used.

Add `__isoc23_` versions for the following interceptors:

* sanitizer_common_interceptors.inc implements strtoimax/strtoumax.
  Remove incorrect FIXME about https://github.com/google/sanitizers/issues/321
* asan_interceptors.cpp implements just strtol and strtoll. The default
  `replace_str` mode checks `nptr` is readable and `endptr` is writable.
  atoi reuses the existing strtol interceptor.
* msan_interceptors.cpp implements strtol family functions and their
  `_l` versions. Tested by lib/msan/tests/msan_test.cpp
* sanitizer_common_interceptors.inc implements scanf family functions.

The strtol family functions are spreaded, which is not great, but the
patch (intended for release/17.x) does not attempt to address the issue.

Add symbols to lib/sanitizer_common/symbolizer/scripts/global_symbols.txt to
support both glibc pre-2.38 and 2.38.

When build bots migrate to glibc 2.38+, we will lose test coverage for
non-isoc23 versions since the existing C++ unittests imply `_GNU_SOURCE`.
Add test/sanitizer_common/TestCases/{strtol.c,scanf.c}.
They catch msan false positive in the absence of the interceptors.

Fix https://github.com/llvm/llvm-project/issues/64388
Fix https://github.com/llvm/llvm-project/issues/64946

Link: https://lists.gnu.org/archive/html/info-gnu/2023-07/msg00010.html
("The GNU C Library version 2.38 is now available")

Reviewed By: #sanitizers, vitalybuka, mgorny

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

(cherry picked from commit ad7e2501000da2494860f06a306dfe8c08cc07c3)

[asan] Intercept atoll and strtoll on Windows

`_MSC_VER>=1800` (Visual Studio 2013) supports atoll/strtoll.
Remove the obsoleted workaround ASAN_INTERCEPT_ATOLL_AND_STRTOLL.

test/asan/TestCases/atoll_strict.c passes but
test/asan/TestCases/strtoll_strict.c doesn't.

(cherry picked from commit 8033231240f223dc7c718d1d27ece2dbcc8057c6)

[clang] Update NumFunctionDeclBits for FunctionDeclBitfields

NumFunctionDeclBits is not updated when DeductionCandidateKind is
incremented.

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

Reviewed By: cor3ntin, balazske, aaron.ballman

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

(cherry picked from commit 91c4b5550ecfbb7afe7275c341b73a6d3a1bbd78)

[clang-format] Fix braced initializer with templated base class

Fixes #64134.

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

(cherry picked from commit 400da115c58ae19445cfdc871a3f559f160fc5c6)

[clang][ExprConstant] Fix crash on uninitialized base class subobject

This patch fixes the reported regression caused by D146358 through adding notes about an uninitialized base class when we diagnose uninitialized constructor.

This also changes the wording from the old one in order to make it clear that the uninitialized subobject is a base class and its constructor is not called.
Wording changes:
BEFORE: `subobject of type 'Base' is not initialized`
AFTER: `constructor of base class 'Base' is not called`

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

Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D153969

Reland "[clang-repl] Adapt to the recent dylib-related changes in ORC."

Original commit message:"

ORC splits into separate dylibs symbols coming from the process and symbols
materialized in the Jit. This patch adapts intent of the existing interface and
adds a regression test to make sure both Jit'd and compiled symbols can be found.

Differential revision: https://reviews.llvm.org/D159115
"

This patch disables the test statement on windows as it seems we might have a
bug in the way we model dllimports.

(cherry picked from commit 452cb7f20bc7b976eb6fec4ac9f2d902f4175c08)

[X86][BF16] Lower FP_EXTEND for vector types under AVX512BF16

Fixes #64460

Reviewed By: RKSimon, skan

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

(cherry picked from commit 6688701497ea8e562b769bdb154a40f4a1099abb)

[Tests][ConstraintElim] autogen newly-added case in large-constant-ints.ll (NFC)

I forgot to do this in 66ec5df3a7f33366455d50769e4e878544becea6 / https://reviews.llvm.org/D158810.

Since this is testing for an assertion failure, the test checks don't matter, but we might as well avoid unnecessary churn the next time someone modifies this test.

(cherry picked from commit df112cba034eefb86d0e92e18518f5e944d58c37)

[ConstraintElim] fix crash with large constants in mul nsw

Another case of https://github.com/llvm/llvm-project/issues/55085.

The added test would trip an assertion due to calling `getSExtValue()` on a value that doesn't fit in int64_t.

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

(cherry picked from commit 66ec5df3a7f33366455d50769e4e878544becea6)

[llvm-exegesis] Use mmap2 when mmap is unavailable to fix riscv32 build

Some 32-bit architectures don't have mmap and define mmap2 instead.
E.g. on riscv32 we may get

```
| /mnt/b/yoe/master/build/tmp/work-shared/llvm-project-source-17.0.0-r0/git/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:1116:19: error: use of undeclared identifier 'SYS_mmap'
|  1116 |   generateSyscall(SYS_mmap, MmapCode);
|       |                   ^
| /mnt/b/yoe/master/build/tmp/work-shared/llvm-project-source-17.0.0-r0/git/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:1134:19: error: use of undeclared identifier 'SYS_mmap'
|  1134 |   generateSyscall(SYS_mmap, GeneratedCode);                                                                                                                                       |       |                   ^
| 1 warning and 2 errors generated.
```

Co-Authored-By: Fangrui Song <i@maskray.me>
Differential Revision: https://reviews.llvm.org/D158375

(cherry picked from commit 01a92f06f23585f15b3e83b7c378d0df2d91e06b)

Fix up release note; NFC

[llvm-rc] Continue to use Argv[0] to resolve executable path

In internal google builds, MainExecPath doesn't go to the directory with `clang`.
Fall back to using Argv0 if MainExecPath doesn't find any clangs.

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

(cherry picked from commit e4eb8d97e8afcb879dc5cd0da7a937dbb26fbf12)

[Driver,X86] Ignore -mfpmath= for assembler input

Some options are only claimed in AddX86TargetArgs/etc (called by
Clang::RenderTargetOptions).
For assembler input, `Add*TargetArgs` is not called. If an option is
unclaimed, it either leads to a -Wunused-command-line-argument warning
or an error (if `TargetSpecific` is set)
```
// clang '-###' --target=x86_64 -mfpmath=sse -c a.s
clang: error: unsupported option '-mfpmath=sse' for target 'x86_64'
```

For -mfpmath=, it's actually claimed by RenderFloatingPointOptions,
which should be moved to AddARMTargetArgs/AddX86TargetArgs later
(non-AArch32-non-x86 targets give a frontend error).
This change is localized and similar to D153691, for release/17.x
backporting.

Fix https://github.com/llvm/llvm-project/issues/65023

Reviewed By: thesamesam

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

(cherry picked from commit 081afa3d04a4bc0d43c62b5b0e5a84f86a8a70ec)

Revert "[clang] Set FP options in Sema when instantiating CompoundStmt"

This reverts commit f1d5ea362577a8a1b5fafe775cf82a449daa3b07.

Revert "[clang] Run test for concrete target"

This reverts commit e54f48384bb213f2c204c74d4e7e08a13904a9d6.

[Driver] Add PIE support on Solaris

`clang` currently lacks PIE support on Solaris.  This patch fixes this,
also linking with `crtbeginS.o` and `crtendS.o` for `-pie` and `-shared`.

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

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

(cherry picked from commit 62945bb811169ffac7cf22c64b6dd3a3ad8d38f0)

[libc++] Fix GNU/Hurd build

GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete.

Reviewed By: #libc, Mordante

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

(cherry picked from commit 1cfcc36812ff7857567f7c729c22ae0e2be0fb3a)

[AArch64] Check opcode before trying to extract register from operand

When matching FNEG patterns for the MachineCombiner we need to check for
opcodes first, before trying to extract a register from an operand.
Otherwise handling of instructions with non-register operands causes the
compiler to crash.

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

(cherry picked from commit 979e8ae4fce64546c65d24864eedd8165bc9787b)

[PowerPC] Exclude frexp(long double) on linux

PowerPC on linux currently don't have support for lowering long double for
frexp().  Removing the tests until implementation is provided.

Reviewed By: #libc, amyk, Mordante

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

(cherry picked from commit 5adac8bebcf26841c1d87227c5043af83a9ef94b)

[BOLT][Instrumentation] Add test for append-pid option

Reviewed By: rafauler

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

(cherry picked from commit dfc759929644ed1ea3224ab30e1086f7acc60da6)

[BOLT][Instrumentation] Fix indirect call profile in PIE

Because indirect call tables use static addresses for call sites, but pc
values recorded by runtime may be subject to ASLR in PIE, we couldn't
find indirect call descriptions by their runtime address in PIE. It
resulted in [unknown] entries in profile for all indirect calls. We need
to substract base address of .text from runtime addresses to get the
corresponding static addresses. Here we create a getter for base address
of .text and substract it's return value from recorded PC values. It
converts them to static addresses, which then may be used to find the
corresponding indirect call descriptions.

Reviewed By: rafauler

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

(cherry picked from commit a86dd9ae60662cfe9f9fb709a33c71d6fec66dfb)

[NFC] [C++20] [Coroutines] Mention the side effect of a fix may bring regressions

The fix we sent for https://github.com/llvm/llvm-project/issues/56301
may bring performance regressions. But we didn't mention it in the
ReleaseNotes so that users may get confused. e.g,
https://github.com/llvm/llvm-project/issues/64933. So this patch
mentions the possible side effect and the potential solutions in
https://github.com/llvm/llvm-project/issues/64945 to avoid
misunderstandings.

[C++20] [Coroutines] Mark await_suspend as noinline if the awaiter is not empty

Close https://github.com/llvm/llvm-project/issues/56301
Close https://github.com/llvm/llvm-project/issues/64151

See the summary and the discussion of https://reviews.llvm.org/D157070
to get the full context.

As @rjmccall pointed out, the key point of the root cause is that
currently we didn't implement the semantics for '@llvm.coro.save' well
("after the await-ready returns false, the coroutine is considered to be
suspended ") well.
Since the semantics implies that we (the compiler) shouldn't write the
spills into the coroutine frame in the await_suspend. But now it is possible
due to some combinations of the optimizations so the semantics are
broken. And the inlining is the root optimization of such optimizations.
So in this patch, we tried to add the `noinline` attribute to the
await_suspend call.

Also as an optimization, we don't add the `noinline` attribute to the
await_suspend call if the awaiter is an empty class. This should be
correct since the programmers can't access the local variables in
await_suspend if the awaiter is empty. I think this is necessary for the
performance since it is pretty common.

Another potential optimization is:

    call @llvm.coro.await_suspend(ptr %awaiter, ptr %handle,
                                  ptr @awaitSuspendFn)

Then it is much easier to perform the safety analysis in the middle
end.
If it is safe to inline the call to awaitSuspend, we can replace it
in the CoroEarly pass. Otherwise we could replace it in the CoroSplit
pass.

Reviewed By: rjmccall

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

[libc++][Modules] locale fails to compile with clang modules when _LIBCPP_LOCALE__L_EXTENSIONS is undefined

When `__locale_dir/locale_base_api/locale_guard.h is` compiled independently, as it is when it's in its own clang module, it fails to compile due to `locale_t` being undefined. It needs to include `__locale` to get that, instead of just `clocale`.

Reviewed By: ldionne, #libc

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

(cherry picked from commit 6021c78fe55e3c4d3e073710bfe279c6a28566d4)

[libc++] Increase the constexpr steps limit on some `bitset` tests.

Prevent these tests from failing on some platforms (the number of
constexpr steps increased by https://reviews.llvm.org/D154860).

(cherry picked from commit 91876eab93a9f0ef29a339ed99bdb1c8ed1e85c6)

[libc++][ranges] Fix `ranges::to` test.

- Make a test for an internal concept libc++-only;
- Make sure that `size` and `capacity` in a test container return the
  same type on all platforms.

(cherry picked from commit 8b9a98661b780a5b50d1d6a1f822d25e0c454382)

[libc++][Modules] Simplify the __std_clang_module header generation

Post review feedback on D157364. Don't section the __std_clang_module header by macro, put the headers in alphabetical order and repeat the macro guards. Restore header_information.header_restrictions.

Reviewed By: ldionne, #libc

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

# Conflicts:
# libcxx/utils/libcxx/header_information.py

[libc++][Modules] Generate the __std_clang_module header

Use header_information to generate the __std_clang_module header. Instead of using lit_header_restrictions like the manually written header did, make a new header_include_requirements to codify what can be included rather than what can be fully tested.

Reviewed By: Mordante, #libc

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

# Conflicts:
# libcxx/utils/libcxx/header_information.py

[libc++][Modules] Remove unnecessary `requires` from the module map

Top level modules don't need `requires` because they're only built when their headers are included.

Reviewed By: ldionne, Mordante, #libc

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

[libc++] Move header_information.py up from tests

I need to use header_information.py in a generator script that isn't for tests in an upcoming change. Move it up a level so that it's in utils/libcxx instead of utils/libcxx/tests.

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

# Conflicts:
# libcxx/test/libcxx/system_reserved_names.gen.py

[libc++] Fix problems with GCC 13 and switch to it in the CI

Reviewed By: #libc, #libc_abi, Mordante

Spies: arphaman, Mordante, libcxx-commits, arichardson

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

Fix regression of D157680

Test cases in D157680 should be target specific, but miss some limit, add them back to make buildbot pass.

Reviewed By: skan, Hahnfeld

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

Fix ODS verifier emission for DerivedAttr when Properties are enabled

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

Fix canonicalizer to copy the entire GreedyRewriteConfig instead of selected fields

It is surprising for the user that only some fields were honored.

Also make the FrozenRewritePatternSet a shared_ptr<const T>.

Fixes #64543

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

Fix MSAN error: use of unitialized value when hashing the MLIR pass manager (NFC)

Fix MLIR pass manager initialization: hash the pass pipeline to detect when initialization is needed

The current logic hashes the context to detect registration changes and re-run
the pass initialization. However it wasn't checking for changes to the
pipeline, so a pass that would get added after a first run would not be
initialized during subsequent runs.

Reviewed By: Mogball

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

Fix some missing fully qualified namespaces in MLIR TableGen generator

Using properties would break when a dialect isn't in the mlir namespace

Fix MLIR build failure: error: no member named 'getValue' in 'mlir::OptionalParseResult'

Fix #63072

Finish renaming getOperandSegmentSizeAttr() from `operand_segment_sizes` to `operandSegmentSizes`

This renaming started with the native ODS support for properties, this is completing it.

A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
 properties.odsOperandSegmentSizes
reverts back to:
 properties.operandSegementSizes

The ODS prefix was creating divergence between all the places and make it harder to
be consistent.

Reviewed By: jpienaar

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

[clang] Run test for concrete target

The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.

(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)

[clang] Set FP options in Sema when instantiating CompoundStmt

When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.

To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.

This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).

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

(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)

clang: Fix x86-no-gather-no-scatter.cpp on macOS after 993bdb047c90e9

On macOS, files are usually below `/Users/...` and clang-cl treats
that as the `/U` flag followed by something instead of as a path.
Put `--` in front of `%s` to make it treat it as a patch, like in
all other tests.

The failure without this change:

    x86-no-gather-no-scatter.cpp:4:14: error: NOGATHER: expected string not found in input
    // NOGATHER: "-target-feature" "+prefer-no-gather"
                 ^
    <stdin>:5:44: note: possible intended match here
    clang: warning: 'x86-no-gather-no-scatter.cpp' treated as the '/U' option [-Wslash-u-filename]
                                               ^

(cherry picked from commit 547ee1c81fceaabcb7064ed525f11f9e94083f56)

[MachineLICM][WinEH] Don't hoist register reloads out of funclets

This fixes https://github.com/llvm/llvm-project/issues/60766

With MSVC style exception-handling (funclets), no registers are
alive when entering the funclet so they must be reloaded from the
stack.  MachineLICM can sometimes hoist such reloads out of the
funclet which is not correct, the register will have been clobbered
when entering the funclet.  This can happen in any loop that
contains a try-catch.

This has been tested on x86_64-pc-window-msvc.  I'm not sure if
funclets work the same on the other windows archs.

Reviewed By: rnk, arsenm

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

(cherry picked from commit 917574d5d8beacbefab4d0e6469dac5b50117832)

[BOLT][Instrumentation] Keep profile open in WatchProcess

When a binary is instrumented with --instrumentation-sleep-time and
instrumentation-wait-forks options and lauched, the profile is
periodically written until all the forks die. The problem is that we
cannot wait for the whole process tree, and we have no way to tell when
it's safe to read the profile. Hovewer, if we keep profile open
throughout the life of the process tree, we can use fuser to determine
when writing is finished.

Reviewed By: rafauler

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

(cherry picked from commit a799298152e3ef08b4919cdaac7a614f7cca9bc6)

[Coroutines] [CoroElide] Don't think exceptional terminator don't leak coro handle unconditionally any more

Close https://github.com/llvm/llvm-project/issues/59723.

The fundamental cause of the above issue is that we assumed the memory
of coroutine frame can be released by stack unwinding automatically
if the allocation of the coroutine frame is elided. But we missed one
point: the stack unwinding has different semantics with the explicit
coroutine_handle<>::destroy(). Since the latter is explicit so it shows
the intention of the user. So we can blame the user to destroy the
coroutine frame incorrectly in case of use-after-free happens. But we
can't do so with stack unwinding.

So after this patch, we won't think the exceptional terminator don't
leak the coroutine handle unconditionally. Instead, we think the
exceptional terminator will leak the coroutine handle too if the
coroutine is leaked somewhere along the search path.

Concretely for C++, we can think the exceptional terminator is not
special any more. Maybe this may cause some performance regressions.
But I've tested the motivating example (std::generator). And on the
other side, the coroutine elision is a middle end opitmization and not
a language feature. So we don't think we should blame such regressions
especially we are correcting the miscompilations.

(cherry picked from commit 7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f)

[CGCall][RISCV] Handle function calls with parameter of RVV tuple type

This was an oversight in D146872, where function calls with tuple type
was not covered. This commit fixes this.

Reviewed By: craig.topper

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

(cherry picked from commit 39a41c8905618fc942100630b4ea37f0cb95e786)

[OpenMP][OMPT] Fix `target enter data` callback ordering & reported device num

This patch fixes: https://github.com/llvm/llvm-project/issues/64738
We observed multiple issues, primarily that the `DeviceId` was reported as -1
in certain scenarios. The reason for this is simply that the device is not
initialized at that point. Hence, we need to move the RAII object creation just
after the `checkDeviceAndCtors`, closer to the actual call we want to observe.

This also solves an odering issue where one `target enter data` callback would
be executed before the `Init` callback.
Additionally, this change will also fix that the callbacks corresponding to
`enter / exit data` and `update` in conjunction with `nowait` would not result
in the emission of an OMPT callback.

Added a testcase to cover initialized device number and `omp target` constructs.

Reviewed By: dhruvachak

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

(cherry picked from commit 57f0bdc8fb1e66d4ed9cfb57f1ef699eefd99646)

[OpenMP][OMPT] Fix reported target pointer for data alloc callback

This patch fixes: https://github.com/llvm/llvm-project/issues/64671
DataOp EMI callbacks would not report the correct target pointer.
This is now alleviated by passing a `void**` into the function which
emits the actual callback, then evaluating that pointer.

Note: Since this is only done after the pointer has been properly
updated, only `endpoint=2` callbacks will show a non-null value.

Reviewed By: dhruvachak, jdoerfert

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

(cherry picked from commit 41f3626f8b300cef24c06d9e8b7cf53029a4330a)

[RISCV] Check type size for lax conversions between RVV builtin types and VectorType::RVVFixedLengthDataVector.

This code was copied from SVE and modified for RVV. For SVE, there
is only one size for builtin types so they didn't need to check
the size. For RVV, due to LMUL there are 7 different sizes of builtin
types so we do need to check the size.

I'm not sure we should have lax vector conversions at all for RVV.
That appears to be contributing to https://github.com/llvm/llvm-project/issues/64404

This patch at least fixes the obvious correctness issue.
This should be backported to LLVM 17.

Reviewed By: jacquesguan

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

(cherry picked from commit 33af2f131db71a18aefc5469129540e2097a537f)

[compiler-rt] Use .globl for FreeBSD/NetBSD interceptor wrappers

On FreeBSD and NetBSD we don't use .weak due to differing semantics.
Currently we end up using no directive, which gives a local symbol,
whereas the closer thing to a weak symbol would be a global one. In
particular, both GNU and LLVM toolchains cannot handle a GOT-indirect
reference to a local symbol at a non-zero offset within a section on
AArch64 (see https://github.com/ARM-software/abi-aa/issues/217), and so
interceptors do not work on FreeBSD/arm64, failing to link with LLD.
Switching to .globl both works around this bug and more closely aligns
such non-weak platforms with weak ones.

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

Reviewed By: MaskRay

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

(cherry picked from commit 7e1afab1b1821550c5f8d0d6a50636236fa02e2c)

Revert "[XCOFF][AIX] Peephole optimization for toc-data."

This reverts commit 5e28d30f1fb10faf2db2f8bf0502e7fd72e6ac2e.

(cherry picked from commit cef56b9318e37e9c47fd356c76c9da522bc8c122)

Revert "[PPC][AIX] Fix toc-data peephole bug and some related cleanup."

This reverts commit b37c7ed0c95c7f24758b1532f04275b4bb65d3c1.

(cherry picked from commit ce658829c9ebd23066f4f0aa5dc686350e5f9ba4)

[InstCombine] Fix select + cast fold with constant expression (PR64669)

The zext constant expression was detected by the fold, but then
handled as a sext. Use ZExtOperator instead of ZExtInst to handle
constant expressions.

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

(cherry picked from commit c15ccfb24afa67d3c3f54e52cc1d1afa564715ed)

[SPARC][IAS] Add support for v9 DONE, RETRY, SAVED, & RESTORED

Add support for DONE, RETRY, SAVED, and RESTORED (v9 Section A.11 & Section A.47).

Those instructions are used for low-level interrupt handling and register window
management by OS kernels.

Reviewed By: barannikov88

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

(cherry picked from commit bf499ec2b96c98633a8b2bc2113b19ffd437f647)

[DAG] replaceStoreOfInsertLoad - don't fold if the inserted element is implicitly truncated

D152276 wasn't handling the case where the inserted element is implicitly truncated into the vector - resulting in a i1 element (implicitly truncated from i8) overwriting 8 bits instead of 1 bit.

This patch is intended to be merged into 17.x so I've just disallowed any vector element vs inserted element type mismatch - technically we could be more elegant and permit truncated stores (as long as the store is still byte sized), but the use cases for that are so limited I'd prefer to play it safe for now.

Candidate patch for #64655 17.x merge

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

(cherry picked from commit ba818c4019c550e1a413e1563a05b241b508defd)

[X86] Add test case for Issue #64655

(cherry picked from commit 2c090e9e67d306578dbeb966a34d9fb85b9f4121)

[RISCV] Support global address as inline asm memory operand of `m`

In D146245, we have supported lowering inline asm `m` with offset
to `register+imm`, but we didn't handle the case that the offset
is the low part of global address.

This patch will emit `%lo(g)` when `g` is a global address.

Fixes #64656

Reviewed By: asb

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

(cherry picked from commit dc60003ec8b2faf595b528a39f64b697a589da06)

[RISCV][NFC] Move tests of inline asm memory constraints to separate file

We will need to check the output of medium code model.

Reviewed By: wangpc

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

(cherry picked from commit a3b11ce78680ef39e4dfbc72085ae3e1814e3cba)

[AArch64] [GlobalISel] Fix clobbered callee saved registers with win64 varargs

This fixes a regression since 1c10d5b175992a9d056a2d763a932e5652386fc1
/ https://reviews.llvm.org/D130903 by applying the same fix from
SelectionDAG from 8cb3667541a94c4fa11b06e19020f753414c1d03 /
https://reviews.llvm.org/D35720.

This could possibly have been detected if the existing testcases
in win64_vararg.ll had been tested with GlobalISel too, but all
the IR snippets there fail to be translated with GlobalISel.

This adds a separate testcase based on real world LLVM IR (instead of
hand-reduced IR), which GlobalISel does translate happily - tested
with both SelectionDAG and GlobalISel.

Before this change, the stack object locations (visible in MIR
with "llc -print-after-all") didn't match with what the prologue
emitted by AArch64FrameLowering actually looked like, which caused
clobbered callee saved registers when function local stack objects
aliased the actual location of the callee saved registers.

This fixes https://github.com/llvm/llvm-project/issues/64740.

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

(cherry picked from commit 955d7615bd7563cc78a5106215daf9e6e47ffb5e)

Remove a release note that should not have snuck in

Remove a merge conflict marker that was missed; NFC

No longer hang on typeof of a function type

We were calling `isFunctionProtoType()` on a `ParsedType` rather than
creating a valid semantic type first and calling the function on that.
The call to `isFunctionProtoType()` would eventually call
`getUnqualifiedDesugaredType()`, which loops indefinitely until we get
a desugared type and a `ParsedType` will never finish desugaring.

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

[BPF] Reset machine register kill mark in BPFMISimplifyPatchable

When LLVM is build with `LLVM_ENABLE_EXPENSIVE_CHECKS=ON` option
the following C code snippet:

    struct t {
      unsigned long a;
    } __attribute__((preserve_access_index));

    void foo(volatile struct t *t, volatile unsigned long *p) {
      *p = t->a;
      *p = t->a;
    }

Causes an assertion:

    $ clang -g -O2 -c --target=bpf -mcpu=v2 t2.c -o /dev/null

    # After BPF PreEmit SimplifyPatchable
    # Machine code for function foo: IsSSA, TracksLiveness
    Function Live Ins: $r1 in %0, $r2 in %1

    bb.0.entry:
      liveins: $r1, $r2
      DBG_VALUE $r1, $noreg, !"t", !DIExpression()
      DBG_VALUE $r2, $noreg, !"p", !DIExpression()
      %1:gpr = COPY $r2
      DBG_VALUE %1:gpr, $noreg, !"p", !DIExpression()
      %0:gpr = COPY $r1
      DBG_VALUE %0:gpr, $noreg, !"t", !DIExpression()
      %2:gpr = LD_imm64 @"llvm.t:0:0$0:0"
      %4:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
      %5:gpr = CORE_LD 344, %0:gpr, @"llvm.t:0:0$0:0"
      STD killed %5:gpr, %1:gpr, 0
      %7:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
      %8:gpr = CORE_LD 344, %0:gpr, @"llvm.t:0:0$0:0"
      STD killed %8:gpr, %1:gpr, 0
      RET

    # End machine code for function foo.

    *** Bad machine code: Using a killed virtual register ***
    - function:    foo
    - basic block: %bb.0 entry (0x6210000e6690)
    - instruction: %7:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
    - operand 2:   killed %2:gpr

This happens because of the way
BPFMISimplifyPatchable::processDstReg() updates second operand of the
`ADD_rr` instruction. Code before `BPFMISimplifyPatchable`:

    .-> %2:gpr = LD_imm64 @"llvm.t:0:0$0:0"
    |
    |`----------------.
    |   %3:gpr = LDD %2:gpr, 0
    |   %4:gpr = ADD_rr %0:gpr(tied-def 0), killed %3:gpr <--- (1)
    |   %5:gpr = LDD killed %4:gpr, 0       ^^^^^^^^^^^^^
    |   STD killed %5:gpr, %1:gpr, 0        this is updated
     `----------------.
        %6:gpr = LDD %2:gpr, 0
        %7:gpr = ADD_rr %0:gpr(tied-def 0), killed %6:gpr <--- (2)
        %8:gpr = LDD killed %7:gpr, 0       ^^^^^^^^^^^^^
        STD killed %8:gpr, %1:gpr, 0        this is updated

Instructions (1) and (2) would be updated to:

    ADD_rr %0:gpr(tied-def 0), killed %2:gpr

The `killed` mark is inherited from machine operands `killed %3:gpr`
and `killed %6:gpr` which are updated inplace by `processDstReg()`.

This commit updates `processDstReg()` reset kill marks for updated
machine operands to keep liveness information conservatively correct.

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

(cherry picked from commit 27026fe5633b546ed647efd99eccdfc598686535)

[X86]Support options -mno-gather -mno-scatter

Gather instructions could lead to security issues, details please refer to https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html.
This supported options -mno-gather and -mno-scatter, which could avoid generating gather/scatter instructions in backend except using intrinsics or inline asms.

Reviewed By: pengfei

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

[SystemZ] Avoid type legalization on structs

In SystemZTTIImpl::getMemoryOpCost, the call to getNumberOfParts will
run type legalization, which can't handle structs. So before that, we
check for an unknown value type and forward to BaseT, just like many
other targets do in this situation.

https://bugzilla.redhat.com/show_bug.cgi?id=2224885

Reviewed By: uweigand

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

(cherry picked from commit 85e4ee15d32ae0344755d11d4ca90a15a6e005cd)

[Driver][unittest] Unbreak ToolChainTest.cpp compilation with -Werror

D157275 broke some buildbots that run with -Werror:

https://lab.llvm.org/buildbot#builders/36/builds/36604
https://lab.llvm.org/buildbot#builders/57/builds/29201

Avoid this by using an overlong line rather than appeasing `clang-format`.

(cherry picked from commit 18252e6c8e2b1bb9901b5cca9e9a75edfeda2c4e)

[Driver] Select newest GCC installation on Solaris

As described in Issue #53709
<https://github.com/llvm/llvm-project/issues/53709>, since
28d58d8fe2094af6902dee7b4d68ec30a3e9d737
<https://reviews.llvm.org/rG28d58d8fe2094af6902dee7b4d68ec30a3e9d737>
`clang` doesn't find the latest of several parallel GCC installations on
Solaris, but only the first in directory order, which is pretty random.

This patch sorts GCC installations in reverse version order so the latest
is picked.

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

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

(cherry picked from commit ae84ad15efd7ef7da95146e900ec72ceadf98058)

Add Requires x86 target to test due to failure in clang-armv8-quick
bot

(cherry picked from commit bb5f64a6fc059fcf81b4b9ffe035f5063956ddd8)

[CodeGen][UBSan] Handle sugared QualTypes correctly in
getUBSanFunctionTypeHash.

getUBSanFunctionTypeHash checks if a Type is a FunctionNoPrototype
by calling isa<FunctionNoProtoType>(). This does not work correctly when
the Type is wrapped in a sugar type such as an AttributedType. This
patch fixes this by using isFunctionNoProtoType() function which removes
sugar and returns the expected result.

The added test is a sanity check that the compiler no longer crashes
during compilation. It also compares the hash with and without the
function attribute for both FunctionNoProtoType and FunctionProtoType.
The hash remains the same for FunctionNoProtoType even with the addition
of an attribute.

rdar://113144087

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

(cherry picked from commit 9afc57dcb2e5cd36ca1ddf0fee3efa958bfd4c2a)

[gcov] Ignore blocks from another file

Constructs such as inline variables, #line, and #include can create
lexical blocks with a different filename.
GCOVProfiling and llvm-cov gcov currently don't handle such cases (see
GCOVLines::writeOut and GCOVFile::readGCNO) and would incorrectly
attribute the line number to the current file.

For now, ignore such blocks. Missing line execution counts is better
than wrong ones.

---

As a workaround that Apple targets don't use -mconstructor-aliases yet,
allow line execution count 4 on the A::A line (1f34e282e8066281eb1447e21e44a2a2e9983e79).

(cherry picked from commit 406e81b79d26dae6838cc69d10a3e22635da09ef)

[libc++][doc] Marks LLVM-17 release notes as final.

Reviewed By: #libc, philnik

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

(cherry picked from commit 71a7192d6927b422c224f5d231300774cb02348a)

LowLevelType: replace a reachable llvm_unreachable with assert

assert is more appropriate here and fixes
`runtime error: execution reached an unreachable program point` in a
-DLLVM_USE_SANITIZER=Undefined build (-fno-sanitize-recover=all causes
llc to exit instead of crash (report_fatal_error)) when testing
MachineVerifier/test_g_assert_[sz]ext.mir.

(cherry picked from commit a7e20dd664bbce6e87b1fdad88d719e497902a42)

[ARM] Fix abs overflow when encoding instructions like strb r1, [r0], #-0

Tested by llvm/test/MC/ARM/basic-thumb2-instructions.s.
Caught by newer -fsanitize=signed-integer-overflow (D156821).

(cherry picked from commit d8900f661a6e451be0ca253df3065254008dd93a)

[llvm-readobj] Fix std::abs overflow after D156821

Tested by llvm/test/tools/llvm-readobj/ELF/relocations.test

(cherry picked from commit 07bb66784c17ef6b98ce38f9cc74d1d92f1aac08)

[RISCV] Fix a UBSAN failure for passing INT64_MIN to std::abs.

clang recently started checking for INT64_MIN being passed to 64-bit std::abs.

Reviewed By: MaskRay

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

(cherry picked from commit 078eb4bd85ddaac530bf2919bb32c6daa6c3e36f)

Reapply "[DebugInfo] Alternate (more efficient) MD5 fix"

D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.

This reverts commit 5956648fc3ba11dd6b0d0f2d1d9b923e7f80f247.
There was a string lifetime issue that is now corrected.

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

(cherry picked from commit 1fcc2bc31bb9352a13445ff4a5cccb0bebb8ea5b)

[CodeGen] Keep track of eagerly emitted globals

An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
    Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]

This reapplies commit f8dadefd4a, reverted in commit 0e17372b38, but
disables RTTI in the test to avoid problems on Windows.

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

(cherry picked from commit c861d32d7c2791bdc058d9d9fbaecc1c2f07b8c7)

[CodeGen] Restrict addEmittedDeferredDecl to incremental extensions

Reemission is only needed in incremental mode. With this early return,
we avoid overhead from addEmittedDeferredDecl in non-incremental mode.

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

(cherry picked from commit d43a3d6346961e639e29b8083b262416889e78ec)

[CodeGen] Clean up access to EmittedDeferredDecls, NFCI.

GlobalDecls should only be added to EmittedDeferredDecls if they
need reemission. This is checked in addEmittedDeferredDecl, which
is called via addDeferredDeclToEmit. Extend these checks to also
handle VarDecls (for lambdas, as tested in Interpreter/lambda.cpp)
and remove the direct access of EmittedDeferredDecls in EmitGlobal
that may actually end up duplicating FunctionDecls.

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

(cherry picked from commit b719e410781ce9f3a2b316afea31c156bf99e036)

[CodeGen] Remove Constant arguments from linkage functions, NFCI.

This was unused since commit dd2362a8ba last year.

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

(cherry picked from commit 2f3fe3ed97bcf778d73eda5aae9f166810a4af02)

[clang-repl] Disambiguate global namespace identifiers

A double colon starts an identifier name in the global namespace and
must be tentatively parsed as such.

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

(cherry picked from commit ba475a4a3440a21e5de6a39a16215836f2614f04)

[lldb] Fix performance regression after adding GNUstep ObjC runtime

We added support for the GNUstep ObjC runtime in 0b6264738f3d. In order to check if the target process uses
GNUstep we run an expensive symbol lookup in `CreateInstance()`. This turned out to cause a heavy performance
regression for non-GNUstep inferiors.

This patch puts a cheaper check in front, so that the vast majority of requests should return early. This
should fix the symptom for the moment. The conceptual question remains: Why does `LanguageRuntime::FindPlugin`
invoke `create_callback` for each available runtime unconditionally in every `Process::ModulesDidLoad`?

Reviewed By: jasonmolenda, jingham, bulbazord

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

(cherry picked from commit af2eb838309d88f046d34bca6055f1de6078fa3b)

[clangd] Avoid passing -xobjective-c++-header to the system include extractor

Fixes https://github.com/clangd/clangd/issues/1568

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

(cherry picked from commit bd74186f1a0831b2c596e87ea056419379a223c1)

Revert "[clang] Preliminary fat-lto-object support"

FatLTO support is only half complete, and shouldn't be included in the
17.x release. https://reviews.llvm.org/D152973.

This reverts commit 5784c47806cf276e8fcc1311201f437cb8169261.
This reverts commit 610fc5cbcc8b68879c562f6458608afe2473ab7f.

[libc++] Fix a few incorrect CMake configuration options

This patch fixes a few CMake options that were set using incorrect
mechanisms.

CMake's man page for the -D <var>=<value> option states: If a command in
the project sets the type to PATH or FILEPATH, then the <value> will be
converted to an absolute path. That's not what we want for most of the
paths we have as configuration options. Otherwise, using -D to set the
configuration option results in an absolute path being used, which
breaks things.

option() denotes a boolean variable, but what was desired was a
string/list variable. Fix this to prevent cmake from changing any
non-empty user provided values to 'ON'.

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

(cherry picked from commit 760261a3daf98882ccbd177e3133fb4a058f47ad)

[libc++] Work around dynamic linking of stringstream::str() on Windows

Also `istringstream::str()` and `ostringstrem::str()`.

https://github.com/llvm/llvm-project/issues/40363 causes `str()`
to be dllimport'ed despite _LIBCPP_HIDE_FROM_ABI.
This is a temporary solution until #40363 is fixed.

Reviewed By: #libc, thakis, philnik

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

(cherry picked from commit 090996f4a1186b1522e1225b6779d74ce9da250c)

AMDGPU: Fix fast f32 exp2

Mirror of the previous log changes, OpenCL conformance doesn't like
interpreting afn as ignore denormal handling but was previously hidden
by flag dropping.

(cherry picked from commit 81b278e613fb3bcdf8053f7a6b5dd2f3881898d2)

AMDGPU: Fix fast f32 log/log10

OpenCL conformance didn't like interpreting afn as ignore the denormal
handling.

https://reviews.llvm.org/D157940
(cherry picked from commit 4b7b4b945856c46b91ade7b6c4264fe8e258367e)

AMDGPU: Fix fast math log2 f32

Apparently afn doesn't allow you to drop the denormal handling
according to OpenCL conformance. This was hidden by losing the flags
during the library linking process. Fast log is still broken and needs
more work.

https://reviews.llvm.org/D157936
(cherry picked from commit e09b3593ba64d004a9d2b3fa41be2ba84f968a88)

[PreISelIntrinsicLowering] Use TLI for correct function

We should query the subtarget of the calling function, not of the
intrinsic.

This probably makes no functional difference (as libcalls are
unlikely to vary across subtargets), but fixes minor compile-time
regressions from unnecessary subtarget instantiations.

Followup to D157567.

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

(cherry picked from commit 66bb7521625826cab6fcc24662c053deee1ef90c)

PreISelIntrinsicLowering: Check RuntimeLibcalls instead of TLI for memory functions

We need a better mechanism for expressing which calls you are allowed
to emit and which calls are recognized. This should be applied to the
17 branch.

(cherry picked from commit c8cac156135de8e211b800ea5abe9666803b2875)

[libc++][PSTL] Disable `-Wpass-failed`.

PSTL contains many pragmas that request loop vectorization, which would
produce a warning when the compiler is unable to fulfill the request (if
`-Wpass-failed` is enabled). This is normal and expected in some cases,
and we don't want `-Werror` to turn that into a compilation failure.

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

(cherry picked from commit 1d340250a894b6ec956e2145b2fc7babbf83e61b)

[SelectionDAG] Use TypeSize variant of ComputeValueVTs to compute correct offsets for scalable aggregate types.

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

[NFC][SelectionDAGBuilder] Use getObjectPtrOffset in place of discrete nodes.

Some prep work to make aggregate loads and stores TypeSize aware.

[SVE] Add test to show incorrect code generation for scalable vector struct loads and stores.

Patch also includes a minor fix to AArch64::isLegalAddressingMode
to ensure all scalable types have a suitable bailout.

[AArch64] Fix crash when neither Neon nor SVE are enabled

The subtarget was unconditionally reporting that SVE was to be used to
lower vectors when Neon was unavailable, even when SVE itself was
unavailable. This decision leads other parts of the compiler to crash,
e.g., when querying SVE vector sizes.

Reviewed By: sdesmalen

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

(cherry picked from commit c058eb998aa6fa89d412984d6cbf9e3f826249f3)

[WebAssembly][Objcopy] Write output section headers identically to inputs

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).

This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.

Reviewed By: jhenderson

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

(cherry picked from commit 1b21067cf247c62c2442daa7ee2d3915249d1ee2)

[RISCV] Stop performFP_TO_INTCombine from folding with ISD::FRINT.

FRINT was added to matchRoundingOp after this function was written.
So FRINT was not tested originally.

For vectors, folding this causes us to create a CSR swap that tries
to write 7 to FRM. This is an illegal value and will cause the CSR
write to fail.

While this might be a legal fold we could do, I'm disabling it for
now so we can backport to LLVM 17 with the least risk.

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

(cherry picked from commit 2df9328fe3a0575fa415964a3c3544b0912b168e)

Reapply [CHR] Fix up phi nodes with unreachable predecessors (PR64594)

Relative to the previous attempt, this also adjusts RegionInfo
verification to allow unreachable predecessors.

-----

If a block in the CHR region has an unreachable predecessor, then
there will be no edge from that predecessor to the newly cloned
block. However, a phi node entry for it will be left behind. Make
sure that these incoming blocks get dropped as well.

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

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

(cherry picked from commit 7e2f1ae7e0ebc7e71ffaa865175aef27fae3b034)

Revert "[Profile] Remove duplicate file locks when enabled continuous mode and online merging."

This reverts commit 985486dca48bffd9e991d9f5ac32e1d109ae000f.

This seems to cause malformed profdata: crbug.com/1469456

(cherry picked from commit 4b08be77c98a4c15b8b3d634fab4ffc24bf4ef38)