- Aug 27, 2023
-
-
Rainer Orth authored
`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)
-
Samuel Thibault authored
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)
-
David Tellenbach authored
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)
-
Lei Huang authored
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)
-
Denis Revunov authored
Reviewed By: rafauler Differential Revision: https://reviews.llvm.org/D154121 (cherry picked from commit dfc75992)
-
Denis Revunov authored
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)
-
Chuanqi Xu authored
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.
-
Chuanqi Xu authored
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
-
Ian Anderson authored
[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)
-
Konstantin Varlamov authored
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)
-
Konstantin Varlamov authored
- 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)
-
Ian Anderson authored
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
-
Ian Anderson authored
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
-
Ian Anderson authored
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
-
Ian Anderson authored
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
-
Nikolas Klauser authored
Reviewed By: #libc, #libc_abi, Mordante Spies: arphaman, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D157060
-
- Aug 25, 2023
-
-
XinWang10 authored
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
-
Mehdi Amini authored
Differential Revision: https://reviews.llvm.org/D158679
-
Mehdi Amini authored
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
-
Mehdi Amini authored
-
Mehdi Amini authored
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
-
Mehdi Amini authored
Using properties would break when a dialect isn't in the mlir namespace
-
Mehdi Amini authored
Fix #63072
-
Mehdi Amini authored
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
-
Serge Pavlov authored
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)
-
Serge Pavlov authored
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)
-
Nico Weber authored
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) -
Karl-Johan Johnsson authored
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)
-
Denis Revunov authored
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)
-
Chuanqi Xu authored
[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)
-
eopXD authored
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)
-
Michael Halkenhaeuser authored
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)
-
Michael Halkenhaeuser authored
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)
-
Craig Topper authored
[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)
-
Jessica Clarke authored
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)
-
- Aug 22, 2023
-
-
Sean Fertile authored
This reverts commit 5e28d30f. (cherry picked from commit cef56b93)
-
Sean Fertile authored
This reverts commit b37c7ed0. (cherry picked from commit ce658829)
-
Nikita Popov authored
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)
-
Koakuma authored
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)
-
Simon Pilgrim authored
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)
-