- Dec 10, 2019
-
-
Sam McCall authored
-
Tibor Brunner authored
Fixes a false positive brought up by PR40633.
-
Peter Collingbourne authored
Differential Revision: https://reviews.llvm.org/D71104
-
Peter Collingbourne authored
Reland 198fbcb8, "Driver: Don't look for libc++ headers in the install directory on Android.", which was reverted in b3249027. Fixed the test case to set --sysroot, which lets it succeed in the case where a directory named "/usr/include/c++/v1" or "/usr/local/include/c++/v1" exists. Original commit message: > The NDK uses a separate set of libc++ headers in the sysroot. Any headers > in the installation directory are not going to work on Android, not least > because they use a different name for the inline namespace (std::__1 instead > of std::__ndk1). > > This effectively makes it impossible to produce a single toolchain that is > capable of targeting both Android and another platform that expects libc++ > headers to be installed in the installation directory, such as Mac. > > In order to allow this scenario to work, stop looking for headers in the > install directory on Android. Differential Revision: https://reviews.llvm.org/D71154
-
Pavel Labath authored
This test was accidentally passing on non-darwin OS because it was explicitly setting the CFLAGS make variable. This meant that (in the default config) it was building with absolutely no debug info, and so setting a breakpoint on a stripped symbol failed, because there was really no trace of it remaining. In other configurations, we were generating the debug info (-gsplit-dwarf implies -g) and the test failed because we did not treat the zeroed out debug info address specially. The test was also xfailed in pretty much every non-standard configuration. This patch fixes the makefile to avoid messing with CFLAGS (use CFLAGS_EXTRAS instead). This causes it to fail in all configurations (except darwin), and so I replace the various decorators with a simple os!=darwin check.
-
Kadir Cetinkaya authored
Summary: Currently we only delete function body from declaration, in addition to that we should also drop ctor initializers. Unfortunately CXXConstructorDecl doesn't store the location of `:` before initializers, therefore we make use of token buffer to figure out where to start deletion. Fixes https://github.com/clangd/clangd/issues/220 Reviewers: hokein, ilya-biryukov Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71188
-
Kadir Cetinkaya authored
Summary: Only function declarations should have the default arguments. This patch makes sure we don't propogate those arguments to out-of-line definitions. Fixes https://github.com/clangd/clangd/issues/221 Reviewers: hokein Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71187
-
Mark Murray authored
Summary: Add VQADDQ, VHADDQ, VRHADDQ, VQSUBQ, VHSUBQ, VQDMULHQ, VQRDMULHQ intrinsics and unit tests. Reviewers: simon_tatham, ostannard, dmgreen, miyuki Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71198
-
Mark Murray authored
Summary: Add VMULL[BT]Q_(INT|POLY) intrinsics and unit tests. Reviewers: simon_tatham, ostannard, dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71066
-
Sean Fertile authored
Refactor FinishCall to be more easily understandable as a precursor to implementing indirect calls for AIX. The refactor tries to group similar code together at the cost of some code duplication. The high level overview of the refactor: - Adds a number of helper functions for things like: * Determining if a call is indirect. * What the Opcode for a call is. * Transforming the callee for a direct function call. * Extracting the Chain operand from a CallSeqStart node. * Building the operands of the call. - Adds helpers for building the indirect call DAG nodes (excluding the call instruction itself which is created in `FinishCall`). - Removes PrepareCall, which has been subsumed by the helpers. - Rename 'InFlag' to 'Glue'. - FinishCall has been refactored to: 1) Set TOC pointer usage on the DAG for the TOC based subtargets. 2) Calculate if a call is indirect. 3) Determine the Opcode to use for the call instruction. 4) Transform the Callee for direct calls, or build the DAG nodes for indirect calls. 5) Buildup the call operands. 6) Emit the call instruction. 7) If needed, emit the callSeqEnd Node and finish lowering by calling `LowerCallResult` Differential Revision: https://reviews.llvm.org/D70126 -
Jonas Devlieghere authored
Guard the Python type map in SBTarget by the SWIGPYTHON define to ensures the rest of the interface can be reused for other languages supported by SWIG.
-
Tatyana Krasnukha authored
-
Simon Tatham authored
I rewrote the isel tablegen for MVE immediate shifts, and accidentally removed the `let Predicates=[HasMVEInt]` that was wrapping the old version, which seems to have allowed those rules to cause trouble on non-MVE targets. That's what I get for only re-running the MVE tests.
-
Mitch Phillips authored
Summary: GWP-ASan test currently fail on 32-bit platforms, as some of the pointers are larger than `uintptr_t` on 32-bit platforms. Fix up all those instances. Also add an uncompress varint test where the result is an underflow. Furthermore, allow multi-init for testing. Each gtest when running `check-gwp_asan` apparently runs in its own instance, but when integrating these tests into Android, this behaviour isn't the same. We remove the global multi-init check here, to allow for testing to work elsewhere, and we're not really worried about multi-init anyway as it's part of our contract with the allocator. Reviewers: eugenis, vlad.tsyrklevich Reviewed By: eugenis Subscribers: #sanitizers, llvm-commits, pcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71121
-
Haojian Wu authored
for d97b3e3e
-
Haojian Wu authored
Reviewers: sammccall, ilya-biryukov Reviewed By: sammccall Subscribers: merge_guards_bot, MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70594
-
- Dec 09, 2019
-
-
Francesco Petrogalli authored
Summary: The tests cover the internal mangling for: 1. Masked signatures. 2. Scalable signatures. 3. Masked scalable signatures with linear. Reviewers: andwar Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71146
-
Simon Tatham authored
Summary: This adds the family of `vshlq_n` and `vshrq_n` ACLE intrinsics, which shift every lane of a vector left or right by a compile-time immediate. They mostly work by expanding to the IR `shl`, `lshr` and `ashr` operations, with their second operand being a vector splat of the immediate. There's a fiddly special case, though. ACLE specifies that the immediate in `vshrq_n` can take values up to //and including// the bit size of the vector lane. But LLVM IR thinks that shifting right by the full size of the lane is UB, and feels free to replace the `lshr` with an `undef` half way through the optimization pipeline. Hence, to keep this legal in source code, I have to detect it at codegen time. Logical (unsigned) right shifts by the element size are handled by simply emitting the zero vector; arithmetic ones are converted into a shift of one bit less, which will always give the same output. In order to do that check, I also had to enhance the tablegen MveEmitter so that it can cope with converting a builtin function's operand into a bare integer to pass to a code-generating subfunction. Previously the only bare integers it knew how to handle were flags generated from within `arm_mve.td`. Reviewers: dmgreen, miyuki, MarkMurrayARM, ostannard Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71065
-
Thomas Raoux authored
The cycle values in modulo scheduling results can be negative. The result of ModuloSchedule::getCycle() must be received as an int type. Patch by Masaki Arai! Differential Revision: https://reviews.llvm.org/D71122
-
Haojian Wu authored
Summary: Previously, xrefs has inconsistent behavior when the reference is inside macro body: - AST-based xrefs (for main file) uses the expansion location; - our index uses the spelling location; This patch makes our index use file locations for references, which is consistent with AST-based xrefs, and kythe as well. After this patch, memory usage of static index on LLVM increases ~5%. Reviewers: ilya-biryukov Subscribers: merge_guards_bot, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70480
-
Michael Liao authored
-
James Henderson authored
See also e84468c1.
-
Zahira Ammarguellat authored
https://reviews.llvm.org/D70691 Fixed the LIT test case. Added the REQUIRES instruction.
-
Muhammad Omair Javaid authored
This patch removes xfail decorator from some lldb testcases which are passing steadily now for past few week/months on aarch64/linux buildbot.
-
James Henderson authored
When committing dba420bc, I missed that a darwin-specific change had been recently introduced into llvm-cxxfilt, which my change ignored and consequently broke the darwin build bot. This change fixes this issue as well as improving naming/commenting of things related to this point so that people are less likely to run into the same issue as I did.
-
Sam McCall authored
Summary: We only do a trivial check whether the region always returns - it has to end with a return statement. Reviewers: kadircet Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70569
-
Sam Elliott authored
-
Sam McCall authored
Summary: Instead, emit a diagnostic and return an empty ASM node, as we do if the target is missing. Filter this diagnostic out in clangd, where it's not meaningful. Fixes https://github.com/clangd/clangd/issues/222 Reviewers: kadircet Subscribers: mgorny, ilya-biryukov, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71189
-
Sam Elliott authored
Summary: These hooks ensure that the RISC-V backend can serialize and parse MIR correctly. Reviewers: jrtc27, luismarques Reviewed By: luismarques Subscribers: hiraditya, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, sameer.abuasal, apazos, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70666
-
Djordje Todorovic authored
Use the newest API. Differential Revision: https://reviews.llvm.org/D71061
-
Jeremy Morse authored
CodeGenPrepare::placeDebugValues moves variable location intrinsics to be immediately after the Value they refer to. This makes tracking of locations very easy; but it changes the order in which assignments appear to the debugger, from the source programs order to the order in which the optimised program computes values. This then leads to PR43986 and PR38754, where variable locations that were in a conditional block are made unconditional, which is highly misleading. This patch adjusts placeDbgValues to only re-order variable location intrinsics if they use a Value before it is defined, significantly reducing the damage that it does. This is still not 100% safe, but the rest of CodeGenPrepare needs polishing to correctly update debug info when optimisations are performed to fully fix this. This will probably break downstream debuginfo tests -- if the instruction-stream position of variable location changes isn't the focus of the test, an easy fix should be to manually apply placeDbgValues' behaviour to the failing tests, moving dbg.value intrinsics next to SSA variable definitions thus: %foo = inst1 %bar = ... %baz = ... void call @llvm.dbg.value(metadata i32 %foo, ... to %foo = inst1 void call @llvm.dbg.value(metadata i32 %foo, ... %bar = ... %baz = ... This should return your test to exercising whatever it was testing before. Differential Revision: https://reviews.llvm.org/D58453
-
David Green authored
The examples are easy to miss.
-
Pavel Labath authored
Summary: This patch deletes the lldb location list parser and teaches the DWARFExpression class to use the parser in llvm instead. I have centralized all the places doing the parsing into a single GetLocationExpression function. In theory the the actual location list parsing should be covered by llvm tests, and this glue code by our existing location list tests, but since we don't have that many location list tests, I've tried to extend the coverage a bit by adding some explicit dwarf5 loclist handling and a test of the dumping code. For DWARF4 location lists this should be NFC (modulo small differences in error handling which should only show up on invalid inputs). In case of DWARF5, this fixes various missing bits of functionality, most notably, the lack of support for DW_LLE_offset_pair. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits, dblaikie Tags: #lldb Differential Revision: https://reviews.llvm.org/D71003
-
Pavel Labath authored
Summary: Lldb support base address selection entries in location lists was broken for a long time. This wasn't noticed until llvm started producing these kinds of entries more frequently with r374600. In r374769, I made a quick patch which added sufficient support for them to get the test suite to pass. However, I did not fully understand how this code operates, and so the fix was not complete. Specifically, what was lacking was the ability to handle modules which were not loaded at their preferred load address (for instance, due to ASLR). Now that I better understand how this code works, I've come to the conclusion that the current setup does not provide enough information to correctly process these entries. In the current setup the location lists were parameterized by two addresses: - the distance of the function start from the start of the compile unit. The purpose of this was to make the location ranges relative to the start of the function. - the actual address where the function was loaded at. With this the function-start-relative ranges can be translated to actual memory locations. The reason for the two values, instead of just one (the load bias) is (I think) MachO, where the debug info in the object files will appear to be relative to the address zero, but the actual code it refers to can be moved and reordered by the linker. This means that the location lists need to be "linked" to reflect the locations in the actual linked file. These two bits of information were enough to correctly process location lists which do not contain base address selection entries (and so all entries are relative to the CU base). However, they don't work with them because, in theory two base address can be completely unrelated (as can happen for instace with hot/cold function splitting, where the linker can reorder the two pars arbitrarily). To fix that, I split the first parameter into two: - the compile unit base address - the function start address, as is known in the object file The new algorithm becomes: - the location lists are processed as they were meant to be processed. The CU base address is used as the initial base address value. Base address selection entries can set a new base. - the difference between the "file" and "load" function start addresses is used to compute the load bias. This value is added to the final ranges to get the actual memory location. This algorithm is correct for non-MachO debug info, as there the location lists correctly describe the code in the final executable, and the dynamic linker can just move the entire module, not pieces of it. It will also be correct for MachO if the static linker preserves relative positions of the various parts of the location lists -- I don't know whether it actually does that, but judging by the lack of base address selection support in dsymutil and lldb, this isn't something that has come up in the past. I add a test case which simulates the ASLR scenario and demonstrates that base address selection entries now work correctly here. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: dblaikie, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70532
-
James Henderson authored
Mostly this adds testing for certain aliases in more explicit ways. There are also a few tidy-ups, and additions of missing testing, where the feature was either not tested at all, or not tested explicitly and sufficiently. Reviewed by: MaskRay, rupprecht, grimar Differential Revision: https://reviews.llvm.org/D71116
-
Mikhail Maltsev authored
Summary: This patch adds intrinsics for the following MVE instructions: * VCADD, VHCADD * VCMUL * VCMLA Each of the above 3 groups has a corresponding new LLVM IR intrinsic. Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: MarkMurrayARM Subscribers: merge_guards_bot, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71190
-
David Green authored
-
Muhammad Omair Javaid authored
This test still fails on Linux aarch64. Tested by buildbot running Ubuntu Bionic Differential Revision: https://reviews.llvm.org/D70722
-
David Green authored
It appears that the cl::bits options are not used anywhere in-tree. In the recent addition to add Callback's to the options, the Callback was missing from this one. This fixes it by adding the same code from the other classes. It also adds a simple test, of sorts, just to make sure these continue compiling.
-
David Green authored
With the extra optimisations we have done, these should now be fine to enable by default. Which is what this patch does. Differential Revision: https://reviews.llvm.org/D70968
-