80332312 made this test pass
in MinGW environments, even if it still is failing in MSVC
environments.

(cherry picked from commit 277fc947)

`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 ad7e2501)

`_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 80332312)

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 91c4b555)

Fixes #64134.

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

(cherry picked from commit 400da115)

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

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 452cb7f2)

Fixes #64460

Reviewed By: RKSimon, skan

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

(cherry picked from commit 66887014)

I forgot to do this in 66ec5df3 / 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 df112cba)

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 66ec5df3)

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 01a92f06)

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 e4eb8d97)

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 081afa3d)

This reverts commit f1d5ea36.

This reverts commit e54f4838.

`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 62945bb8)

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 1cfcc368)

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 979e8ae4)

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 5adac8be)

Reviewed By: rafauler

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

(cherry picked from commit dfc75992)

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 a86dd9ae)

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.

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 6021c78f)

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

(cherry picked from commit 91876eab)

- 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 8b9a9866)

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

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

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

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

Reviewed By: #libc, #libc_abi, Mordante

Spies: arphaman, Mordante, libcxx-commits, arichardson

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

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

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

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 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

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

Fix #63072

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