- Jan 03, 2022
-
-
Louis Dionne authored
We don't cross-compile to 32 bits in the CI anymore.
-
Louis Dionne authored
-
John Ericson authored
In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
-
LLVM GN Syncbot authored
-
ksyx authored
This commit resolves GitHub issue #45895 (Bugzilla #46550), to add or remove empty line between definition blocks including namespaces, classes, structs, enums and functions. Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D116314
-
G. Pery authored
My team has a vendetta against lines ending with an open parenthesis, thought it might be useful for others too
😊 Reviewed By: HazardyKnusperkeks, curdeius Differential Revision: https://reviews.llvm.org/D116170 -
Philip Reames authored
This reverts commit 9bd22595. Seeing some bot failures which look plausibly connected. Revert while investigating/waiting for bots to stablize. e.g. https://lab.llvm.org/buildbot#builders/36/builds/15933
-
Craig Topper authored
This function returns an upper bound on the number of bits needed to represent the signed value. Use "Max" to match similar functions in KnownBits like countMaxActiveBits. Rename APInt::getMinSignedBits->getSignificantBits. Keeping the old name around to keep this patch size down. Will do a bulk rename as follow up. Rename KnownBits::countMaxSignedBits->countMaxSignificantBits. Reviewed By: lebedev.ri, RKSimon, spatel Differential Revision: https://reviews.llvm.org/D116522
-
Kazu Hirata authored
This reverts commit fd480888. This patch causes gcc to issue a lot of warnings like: warning: base class ‘class llvm::MCParsedAsmOperand’ should be explicitly initialized in the copy constructor [-Wextra]
-
Aaron Ballman authored
-
Sam McCall authored
http://45.33.8.238/win/51774/step_4.txt MS extension causes the wrong class to be friended.
-
Sam McCall authored
Implementation is based on the "expected type" as used for designated-initializers in braced init lists. This means it can deduce the type in some cases where it's not written: void foo(Widget); foo({ /*help here*/ }); Only basic constructor calls are in scope of this patch, excluded are: - aggregate initialization (no help is offered for aggregates) - initializer_list initialization (no help is offered for these constructors) Fixes https://github.com/clangd/clangd/issues/306 Differential Revision: https://reviews.llvm.org/D116317
-
Erik Desjardins authored
MOV64ri results in a significantly longer encoding, and use of this operator is fairly avoidable as we can always check the size of the immediate we're using. This is an updated version of D99045. Co-authored-by:
Simonas Kazlauskas <git@kazlauskas.me> Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D116458
-
Erik Desjardins authored
Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D116420
-
Michael Zimmermann authored
There is some similar looking code in `TokenAnnotator.cpp` but given that I've never worked on clang-format before I don't know what the purpose of that code is and how it's related to `UnwrappedLineParser.cpp`. Either way, it fixes clang-format with `BraceWrapping.AfterEnum=true` and `AllowShortEnumsOnASingleLine=false` to behave like the documentation says. Before this patch: ``` enum { A, B } myEnum; ``` After this patch: ``` enum { A, B } myEnum; ``` According to the unittests which I had to modify this would change the LLVM style. Please evaluate if you want to change the defaults or if you consider the current style a bug. Reviewed By: curdeius, HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D106349
-
Alexandre Ganea authored
-
Alexandre Ganea authored
Differential Revision: https://reviews.llvm.org/D116313
-
John Ericson authored
In that revision, I make LLD match Clang in deprecating `llvm-config`. This patch isn't to worthwhile on its own --- there isn't a sense in which the new order is "better" in isolation --- but by putting the steps that LLD also neeeds to do first, I make the diff between LLD and Clang's top-level `CMakeLists.txt` very legible. Longer term I hope: 1. We can remove calling `llvm-config` altogether, and just go strait to finding the CMake config file. This is what Flang does, at least. 2. Hopefully the diffable part is smaller then --- i.e. there is less duplicated boilerplate. 3. Any duplicate boilerplate that remains can be factored out. I didn't both trying to factor anything out in e.g. the top level common CMake Utility modules because this deprecated-but-not-removed state is a merely transitional. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116548
-
Chris Bieneman authored
As Visual Studio's CMake support is getting better and better the line between IDE generator and non-IDE generators is blurring. Visual Studio 2019 and later have a very useful UI that can handle all of the various targets we create, but if they are unsorted it is wildly unwieldy. This change sorts the lit testsuite targets and per-component install targets into folders, which are not generated for IDE generators but are generated by default under Visual Studio's CMake + Ninja integration.
-
Craig Topper authored
Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D116516
-
Craig Topper authored
-
Philip Reames authored
If we have an exit which is controlled by a loop invariant condition and which dominates the latch, we know only the copy in the first unrolled iteration can be taken. All other copies are dead. The change itself is pretty straight forward, but let me add two points of context: * I'd have expected other transform passes to catch this after unrolling, but I'm seeing multiple examples where we get to the end of O2/O3 without simplifying. * I'd like to do a stronger change which did CSE during unroll and accounted for invariant expressions (as defined by SCEV instead of trivial ones from LoopInfo), but that doesn't fit cleanly into the current code structure. Differential Revision: https://reviews.llvm.org/D116496
-
Philip Reames authored
Reviewer suggested this was more in spirit of the original tests.
-
Louis Dionne authored
There is an ongoing CI outage with our Linux nodes, so I temporarily set up a couple of nodes. These nodes will be much slower than the usual ones and there's only a few of them, so I am temporarily disabling most of our CI to keep things working.
-
RitanyaB authored
Segmentation fault in ompt_tsan_dependences function due to an unchecked NULL pointer dereference is as follows: ``` ThreadSanitizer:DEADLYSIGNAL ==140865==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000050 (pc 0x7f217c2d3652 bp 0x7ffe8cfc7e00 sp 0x7ffe8cfc7d90 T140865) ==140865==The signal is caused by a READ memory access. ==140865==Hint: address points to the zero page. /usr/bin/addr2line: DWARF error: could not find variable specification at offset 1012a /usr/bin/addr2line: DWARF error: could not find variable specification at offset 133b5 /usr/bin/addr2line: DWARF error: could not find variable specification at offset 1371a /usr/bin/addr2line: DWARF error: could not find variable specification at offset 13a58 #0 ompt_tsan_dependences(ompt_data_t*, ompt_dependence_t const*, int) /ptmp/bhararit/llvm-project/openmp/tools/archer/ompt-tsan.cpp:1004 (libarcher.so+0x15652) #1 __kmpc_doacross_post /ptmp/bhararit/llvm-project/openmp/runtime/src/kmp_csupport.cpp:4280 (libomp.so+0x74d98) #2 .omp_outlined. for_ordered_01.c:? (for_ordered_01.exe+0x5186cb) #3 __kmp_invoke_microtask /ptmp/bhararit/llvm-project/openmp/runtime/src/z_Linux_asm.S:1166 (libomp.so+0x14e592) #4 __kmp_invoke_task_func /ptmp/bhararit/llvm-project/openmp/runtime/src/kmp_runtime.cpp:7556 (libomp.so+0x909ad) #5 __kmp_fork_call /ptmp/bhararit/llvm-project/openmp/runtime/src/kmp_runtime.cpp:2284 (libomp.so+0x8461a) #6 __kmpc_fork_call /ptmp/bhararit/llvm-project/openmp/runtime/src/kmp_csupport.cpp:308 (libomp.so+0x6db55) #7 main ??:? (for_ordered_01.exe+0x51828f) #8 __libc_start_main ??:? (libc.so.6+0x24349) #9 _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120 (for_ordered_01.exe+0x4214e9) ThreadSanitizer can not provide additional info. SUMMARY: ThreadSanitizer: SEGV /ptmp/bhararit/llvm-project/openmp/tools/archer/ompt-tsan.cpp:1004 in ompt_tsan_dependences(ompt_data_t*, ompt_dependence_t const*, int) ==140865==ABORTING ``` To reproduce the error, use the following openmp code snippet: ``` /* initialise testMatrixInt Matrix, cols, r and c */ #pragma omp parallel private(r,c) shared(testMatrixInt) { #pragma omp for ordered(2) for (r=1; r < rows; r++) { for (c=1; c < cols; c++) { #pragma omp ordered depend(sink:r-1, c+1) depend(sink:r-1,c-1) testMatrixInt[r][c] = (testMatrixInt[r-1][c] + testMatrixInt[r-1][c-1]) % cols ; #pragma omp ordered depend (source) } } } ``` Compilation: ``` clang -g -stdlib=libc++ -fsanitize=thread -fopenmp -larcher test_case.c ``` It seems like the changes introduced by the commit https://reviews.llvm.org/D114005 causes this particular SEGV while using Archer. Reviewed By: protze.joachim Differential Revision: https://reviews.llvm.org/D115328
-
Sam McCall authored
There are some limitations here, so this is behind a flag for now (in addition to the config setting for the overall feature). - symbols without exactly one associated header aren't handled right - no macro support - referencing std::size_t usually doesn't leave any trace in the AST that the alias in std was used, so we associate with stddef.h instead of cstddef. (An AST issue not specific to stdlib, but much worse there) Differential Revision: https://reviews.llvm.org/D114077
-
LLVM GN Syncbot authored
-
Sam McCall authored
To be used in D116490 and D116385, and an upcoming patch to generate C++ constructors. Differential Revision: https://reviews.llvm.org/D116502
-
Sam McCall authored
This mechanism is used almost exclusively to enable extra warnings in clang-tidy using ExtraArgs=-Wfoo, Checks="clang-diagnostic-foo". Its presence is a strong signal that these flags are useful. We choose not to actually emit them as clang-tidy diagnostics, but under their "main" name - this ensures we show the same diagnostic in a consistent way. We don't add the ExtraArgs to the compile command in general, but rather just handle the -W<group> flags, which is the common case and avoids unexpected side-effects. And we only do this for the main file parse, when producing diagnostics. Differential Revision: https://reviews.llvm.org/D116147
-
Michael Liao authored
- This partially reverts d677a7cb to pacify GCC warnings like ``` base class should be explicitly initialized in the copy constructor ``` - Shall we keep turning on option `IgnoreBaseInCopyConstructors` when enabling `readability-redundant-member-init` check?
-
Tomas Matheson authored
This patch introduces support for targetting the Armv9.3-A architecture, which should map to the existing Armv8.8-A extensions. Differential Revision: https://reviews.llvm.org/D116159
-
Alexander Belyaev authored
After https://reviews.llvm.org/D115821 it became possible to create `tensor<elem_type>` with a single `tensor.from_elements` operation without collapsing tensor shape from `tensor<1xelem_type>` to `tensor<elem_type>` Differential Revision: https://reviews.llvm.org/D115891
-
Sam McCall authored
Provide signature while typing template arguments: Foo< ^here > Here the parameters are e.g. "typename x", and the result type is e.g. "struct" (class template) or "int" (variable template) or "bool (std::string)" (function template). Multiple overloads are possible when a template name is used for several overloaded function templates. Fixes https://github.com/clangd/clangd/issues/299 Differential Revision: https://reviews.llvm.org/D116352
-
LLVM GN Syncbot authored
-
Pavel Labath authored
This survived the reproducer deletion.
-
Uday Bondhugula authored
Fix confusing diagnostic during partial dialect conversion. A failure to legalize is not the same as an operation being illegal: for eg. an operation neither explicity marked legal nor explicitly marked illegal could have been generated and may have failed to legalize further. The op isn't an illegal one per https://mlir.llvm.org/docs/DialectConversion/#conversion-target which is an op that is explicitly marked illegal. Differential Revision: https://reviews.llvm.org/D116152
-
William S. Moses authored
Create folders for add(sub(a, b), b) -> a and add(b, sub(a, b)) -> a Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D116471
-
Pavel Labath authored
Both serve the same purpose (finding shared libraries) and allow one to launch a dynamically linked executable by just specifying the platform sysroot.
-
Pavel Labath authored
The lldb-server code is currently set up in a way that each NativeProcess instance does its own waitpid handling. This works fine for BSDs, where the code can do a waitpid(process_id), and get information for all threads in that process. The situation is trickier on linux, because waitpid(pid) will only return information for the main thread of the process (one whose tid == pid). For this reason the linux code does a waitpid(-1), to get information for all threads. This was fine while we were supporting just a single process, but becomes a problem when we have multiple processes as they end up stealing each others events. There are two possible solutions to this problem: - call waitpid(-1) centrally, and then dispatch the events to the appropriate process - have each process call waitpid(tid) for all the threads it manages This patch implements the second approach. Besides fitting better into the existing design, it also has the added benefit of ensuring predictable ordering for thread/process creation events (which come in pairs -- one for the parent and one for the child). The first approach OTOH, would make this ordering even more complicated since we would have to keep the half-threads hanging in mid-air until we find the process we should attach them to. The downside to this approach is an increased number of syscalls (one waitpid for each thread), but I think we're pretty far from optimizing things like this, and so the cleanliness of the design is worth it. The included test reproduces the circumstances which should demonstrate the bug (which manifests as a hung test), but I have not been able to get it to fail. The only place I've seen this failure modes are very rare hangs in the thread sanitizer tests (tsan forks an addr2line process to produce its error messages). Differential Revision: https://reviews.llvm.org/D116372
-
Nikita Popov authored
The nounwind and uwtable attributes will get handled as part of the loop below as well, there is no need to special-case them here.
-