- Jan 14, 2022
-
-
Nikolas Klauser authored
Add `std::ranges::in_in_result` Reviewed By: Quuxplusone, Mordante, #libc Spies: ldionne, libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D116278
-
Peixin-Qiao authored
OpenMP runtime requires depend vec with i64 type and the alignment of store instruction should be set as 8. Reviewed By: kiranchandramohan, shraiysh Differential Revision: https://reviews.llvm.org/D116300
-
Bryce Wilson authored
-
Casey Carter authored
... from testing with MSVC's STL. Mostly truncation warnings and variables that are only used in `LIBCPP_ASSERT`. Differential Revision: https://reviews.llvm.org/D116878
-
Peter Klausler authored
Accept the legacy specific intrinsic names BABS, IIABS, JIABS, KIABS, and ZABS as well. Differential Revision: https://reviews.llvm.org/D117155
-
Dave Lee authored
Update examples and docs to demonstrate using `__lldb_init_module` instead of the idiom that checks for `lldb.debugger` at the top-level. ``` if __name__ == '__main__': ... elif lldb.debugger: ... ``` Is replaced with: ``` if __name__ == '__main__': ... def __lldb_init_module(debugger, internal_dict): ... ``` This change is for two reasons. First, it's generally encouraged not to only use the convenience singletons (`lldb.{debugger,process,target,etc}`) interactively from the `script` command. Second, there's a bug where registering a python class as a command (using `command script add -c ...`), result in the command not being runnable. Note that registering function-backed commands does not have this bug. Differential Revision: https://reviews.llvm.org/D117237 -
Fangrui Song authored
This fixes -fno-semantic-interposition -fsanitize-coverage incompatibility. -fPIC -fno-semantic-interposition may add dso_local to an external linkage function. -fsanitize-coverage instrumentation does not clear dso_local when adding comdat nodeduplicate. This causes a compatibility issue: the function symbol may be referenced by a PC-relative relocation without using the local alias. In -shared mode, ld will report a relocation error. The fix is to either clear dso_local when adding comdat nodeduplicate, or supporting comdat nodeduplicate. The latter is more appropriate, because a comdat nodeduplicate is like not using comdat. Note: The comdat condition was originally added by D77429 to not use local alias for a hidden external linkage function in a deduplicate comdat. The condition has been unused since the code was refactored to only use local alias for default visibility symbols. Note: `canBenefitFromLocalAlias` is used by clang/lib/CodeGen/CodeGenModule.cpp and we don't want to add dso_local to default visibility external linkage comdat any (clang/test/CodeGenCUDA/usual-deallocators.cu). Differential Revision: https://reviews.llvm.org/D117190
-
Peter Klausler authored
It's not conforming to specify the SAVE attribute more than once for a variable, but it also doesn't hurt anything and isn't fatal in other Fortran compilers. Downgrade the message to a warning for better portability. Differential Revision: https://reviews.llvm.org/D117153
-
James Y Knight authored
Causes a crash with the following (creduce'd) test-case: clang -O3 '--target=aarch64-grtev4-linux-gnu' -xc - -c -o /dev/null <<EOF int *e; int f; int g() { int h; int *j = 0; while (&f - j > 0) { int k; k = j; if (e == j && *e) k = 5; h = k; j++; } return h; } EOF This reverts commit 7ce48be0. -
Philip Reames authored
[MemoryBuiltins] Demote isCallocLikeFn and isAlignedAllocLikeFn to local helpers after removal of last external use [NFC]
-
Fangrui Song authored
Similar to D116843. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D116844
-
Fangrui Song authored
Clang 13 has a -fsanitize-coverage -fno-semantic-interposition bug (D117190) which may lead to `relocation R_X86_64_PC32 cannot be used against symbol` linker error in -DLLVM_USE_SANITIZE_COVERAGE=ON build when a shared object is built (e.g. -DLLVM_BUILD_LLVM_DYLIB=on). For simplicity, just disallow Clang 13 entirely. Note: GCC -fPIC performance benefits from -fno-semantic-interposition dramatically. Clang benefits little. Using this option is more for a dogfood purpose to test correctness of this option, because in the wild some important packages like CPython uses this option. Differential Revision: https://reviews.llvm.org/D117183
-
Philip Reames authored
This completes removal of the isXLike queries, and depends on a whole series of earlier patches which have already landed. Differential Revision: https://reviews.llvm.org/D117242
-
Philip Reames authored
[Attributor] Share code for abstract interpretation of allocation sizes with getObjectSize [NFC-ish] The basic idea is that we can parameterize the getObjectSize implementation with a callback which lets us replace the operand before analysis if desired. This is what Attributor is doing during it's abstract interpretation, and allows us to have one copy of the code. Note this is not NFC for two reasons: * The existing attributor code is wrong. (Well, this is under-specified to be honest, but at least inconsistent.) The intermediate math needs to be done in the index type of the pointer space. Imagine e.g. i64 arguments in a 32 bit address space. * I did not preserve the behavior in getAPInt where we return 0 for a partially analyzed value. This looks simply wrong in the original code, and nothing test wise contradicts that. Differential Revision: https://reviews.llvm.org/D117241
-
Jonas Devlieghere authored
When LLDB receives a SIGINT while running the embedded Python REPL it currently just crashes in ScriptInterpreterPythonImpl::Interrupt with an error such as the one below: Fatal Python error: PyThreadState_Get: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL) The faulty code that causes this error is this part of ScriptInterpreterPythonImpl::Interrupt: PyThreadState *state = PyThreadState_GET(); if (!state) state = GetThreadState(); if (state) { long tid = state->thread_id; PyThreadState_Swap(state); int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt); The obvious fix I tried is to just acquire the GIL before this code is running which fixes the crash but the KeyboardInterrupt we want to raise immediately is actually just queued and would only be raised once the next line of input has been parsed (which e.g. won't interrupt Python code that is currently waiting on a timer or IO from what I can see). Also none of the functions we call here is marked as safe to be called from a signal handler from what I can see, so we might still end up crashing here with some bad timing. Python 3.2 introduced PyErr_SetInterrupt to solve this and the function takes care of all the details and avoids doing anything that isn't safe to do inside a signal handler. The only thing we need to do is to manually setup our own fake SIGINT handler that behaves the same way as the standalone Python REPL signal handler (which raises a KeyboardInterrupt). From what I understand the old code used to work with Python 2 so I kept the old code around until we officially drop support for Python 2. There is a small gap here with Python 3.0->3.1 where we might still be crashing, but those versions have reached their EOL more than a decade ago so I think we don't need to bother about them. Differential revision: https://reviews.llvm.org/D104886 -
Mehdi Amini authored
-
Mehdi Amini authored
-
Mehdi Amini authored
-
Mehdi Amini authored
-
Mehdi Amini authored
-
Bryce Wilson authored
Differential Revision: https://reviews.llvm.org/D117245
-
Mehdi Amini authored
This reverts commit 778a264d. This broke the bot: tests are failing at the moment.
-
Mehdi Amini authored
Differential Revision: https://reviews.llvm.org/D117251
-
Aart Bik authored
(1) copy-and-past error in encoding alias name: this is an annotation for a tensor (3-d) not a matrix (2-d). (2) typo in "initialization" Reviewed By: bixia Differential Revision: https://reviews.llvm.org/D117255 -
Peter Klausler authored
This is nonconformant usage, but widely accepted as an extension. Downgrade the error message to a warning. Differential Revision: https://reviews.llvm.org/D117152
-
Lang Hames authored
This reapplies 253ce928, which was reverted in 66b2ed47 due to bot failures. I have added the `-phony-externals` option added, which should fix the unresolved symbol errors.
-
Bixia Zheng authored
Add TACO tests to test/Integration/Dialect/SparseTensor/taco. Add the MLIR PyTACO implementation as tools under the directory. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D117126
-
Arthur Eubanks authored
Previously we limited ourselves to only internal/private functions. We can also delete linkonce_odr functions. Minor compile time wins: https://llvm-compile-time-tracker.com/compare.php?from=d51e3474e060cb0e90dc2e2487f778b0d3e6a8de&to=bccffe3f8d5dd4dda884c9ac1f93e51772519cad&stat=instructions Major memory wins on tramp3d: https://llvm-compile-time-tracker.com/compare.php?from=d51e3474e060cb0e90dc2e2487f778b0d3e6a8de&to=bccffe3f8d5dd4dda884c9ac1f93e51772519cad&stat=max-rss Relanding with fix for compile times D117236. Reviewed By: nikic, mtrofin Differential Revision: https://reviews.llvm.org/D115545
-
Jon Chesterfield authored
Fixes github issues/52910 Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D117230
-
Arthur Eubanks authored
If a function has many uses, this can take a good chunk of compile times. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117236
-
Peter Klausler authored
We already accept assignments of INTEGER to LOGICAL (& vice versa) as an extension, but not initialization. Extend initialization to cover those cases. (Also fix misspelling in nearby comment as suggested by code reviewer.) Decouple an inadvertent dependence cycle by moving two one-line function definitions into a header file. Differential Revision: https://reviews.llvm.org/D117159
-
Whitney Tsang authored
getLoopIndex() is added to get the loop index of a given loop. getLoopsAtDepth() is added to get the loops in the nest at a given depth. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D115590
-
Roman Lebedev authored
-
Congzhe Cao authored
This patch enables loop interchange with multiple outer loop induction variables, and hence removes the limitation that only a single outer loop induction variable is supported. In fact, it turns out that the current pass already trivially supports multiple outer indvars, which is the result of a previous patch `https://reviews.llvm.org/D102743`. Therefore, this patch removed that limitation and provides test cases for multiple outer indvars. Reviewed By: bmahjour Differential Revision: https://reviews.llvm.org/D114916
-
Philip Reames authored
-
Venkata Ramanaiah Nalamothu authored
Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D117243
-
Jack Kirk authored
Adds NVPTX intrinsics and builtins for CUDA PTX cvt instructions for sm80 architectures and above. Requires ptx 7.0. PTX ISA description of cvt instructions : https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-cvt Signed-off-by:
JackAKirk <jack.kirk@codeplay.com> Differential Revision: https://reviews.llvm.org/D116673
-
Sam McCall authored
During pop() we convert nodes into spans of expanded syntax::Tokens. If we precompute a range of plausible (expanded) tokens, then we can do an extremely cheap approximate hit-test against it, because syntax::Tokens are ordered by pointer. This would seem not to buy anything (we don't enter nodes unless they overlap the selection), but in fact the spans we have are for *newly* claimed ranges (i.e. those unclaimed by any child node). So if you have: { { [[2+2]]; } } then all of the CompoundStmts pass the hit test and are pushed, but we skip full hit-testing of the brackets during pop() as they lie outside the range. This is ~10x average speedup for selectiontree on a bad case I've seen (large gtest file). Differential Revision: https://reviews.llvm.org/D117107 -
Sam McCall authored
Not sure it's OK to suppress this in clang itself - if we're building a PCH or module, maybe it matters? Differential Revision: https://reviews.llvm.org/D116925
-