`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

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 73e5a70e)

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 0baf85c3)

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 547ee1c8)

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 917574d5)

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

[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 7037331a)

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 39a41c89)

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 57f0bdc8)

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 41f3626f)

[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 33af2f13)

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

This reverts commit 5e28d30f.

(cherry picked from commit cef56b93)

This reverts commit b37c7ed0.

(cherry picked from commit ce658829)

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

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

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