summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Don't double emit option groupsRaphael Isemann2019-07-181-1/+0
| | | | | | | | | We currently emit the option groups twice if Groups<[1,2,3]> is used in the tablegen. This leads to compilation errors. This patch just removes the line that accidentially emits the option group a second time. llvm-svn: 366414
* Fix asan infinite loop on undefined symbolSerge Guelton2019-07-182-2/+49
| | | | | | | | Fix llvm#39641 Differential Revision: https://reviews.llvm.org/D63877 llvm-svn: 366413
* [RISCV] Reset NoPHIS MachineFunctionProperty in emitSelectPseudoAlex Bradbury2019-07-181-0/+1
| | | | | | | We insered PHIS were there were none before, so the property must be reset. This error was found on an EXPENSIVE_CHECKS build. llvm-svn: 366412
* [LoopInfo] Use early return in branch weight update functions. NFC.Serguei Katkov2019-07-181-29/+30
| | | | llvm-svn: 366411
* [RISCV][DebugInfo] Fix dwarf-riscv-relocs.ll test on WindowsAlex Bradbury2019-07-181-1/+1
| | | | | | | | | Windows sees DW_AT_decl_file (".\dwarf-riscv-relocs.c") while Linux sees DW_AT_decl_file ("./dwarf-riscv-relocs.c"). This fixes a failure introduced in rL366402. llvm-svn: 366410
* [CodeComplete] Fix ASTUnit cached completion of macros from preamble, broken ↵Sam McCall2019-07-183-4/+6
| | | | | | | | | | | | | | | | | | in r342528 Summary: The problem is the default LoadExternal with no completer, which happens when loading global results. Reviewers: ilya-biryukov, nik Subscribers: arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64864 llvm-svn: 366409
* clang-tidy release notes: Split and order changes by typeHans Wennborg2019-07-181-58/+61
| | | | | | Patch by Eugene Zelenko! llvm-svn: 366408
* [NFC][PowerPC] Add the test to test the pass block-placementKang Zhang2019-07-182-1/+318
| | | | llvm-svn: 366407
* [PowerPC][Clang] Remove use of malloc in mm_mallocQiu Chaofan2019-07-183-44/+8
| | | | | | | | | | | Remove dependency of malloc in implementation of mm_malloc function in PowerPC intrinsics and alignment assumption on glibc. Reviewed By: Hal Finkel Differential Revision: https://reviews.llvm.org/D64850 llvm-svn: 366406
* [X86] Disable combineConcatVectors for vXi1 vectors.Craig Topper2019-07-182-116/+116
| | | | | | | | | | | I'm not convinced the code this calls is properly vetted for vXi1 vectors. Experimental vector widening legalization testing for D55251 is now hitting an assertion failure inside EltsFromConsecutiveLoads. This is occurring from a v2i1 load having a store size different than its VT size. Hopefully this commit will keep such issues from happening. llvm-svn: 366405
* Fix typo in programmer's manual cantFile -> cantFailNathan Lanza2019-07-181-1/+1
| | | | llvm-svn: 366403
* [DWARF][RISCV] Add support for RISC-V relocations needed for debug infoAlex Bradbury2019-07-1810-13/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When code relaxation is enabled many RISC-V fixups are not resolved but instead relocations are emitted. This happens even for DWARF debug sections. Therefore, to properly support the parsing of DWARF debug info we need to be able to resolve RISC-V relocations. This patch adds: * Support for RISC-V relocations in RelocationResolver * DWARF support for two relocations per object file offset * DWARF changes to support relocations in more DIE fields The two relocations per offset change is needed because some RISC-V relocations (used for label differences) come in pairs. Relocations can also be emitted for DWARF fields where relocations were not yet evaluated. Adding relocation support for some of these fields is essencial. On the other hand, LLVM currently emits RISC-V relocations for fixups that could be safely evaluated, since they can never be affected by code relaxations. This patch also adds relocation support for the fields affected by those extraneous relocations (the DWARF unit entry Length, and the DWARF debug line entry TotalLength and PrologueLength), for testing purposes. Differential Revision: https://reviews.llvm.org/D62062 Patch by Luís Marques. llvm-svn: 366402
* [ELF][test] Merge/rename some basic*.s testsFangrui Song2019-07-183-239/+40
| | | | | | | | | | basic64be.s is a big-endian powerpc64 test that just duplicates what basic-ppc64.s does. Extend basic-ppc64.s to add big-endian tests. Delete basic64be.s Rename basic32.s to basic-i386.s llvm-svn: 366401
* [clangd] Fix Fix -Wunused-lambda-capture after r366339Fangrui Song2019-07-181-4/+3
| | | | llvm-svn: 366400
* [RISCV] Re-land r366331 d RISCV to LLVM_ALL_TARGETSAlex Bradbury2019-07-181-0/+1
| | | | | | *San flagged issues should be now be addressed. llvm-svn: 366399
* [RISCV] Avoid signed integer overflow UB in RISCVMatInt::generateInstSeqAlex Bradbury2019-07-181-1/+1
| | | | | | Found by UBSan. llvm-svn: 366398
* [RISCV] Don't acccess an invalidated iterator in RISCVInstrInfo::removeBranchAlex Bradbury2019-07-181-2/+2
| | | | | | Issue found by ASan. llvm-svn: 366397
* [AArch64] Add dependency from AArch64CodeGen to TransformUtils to fix ↵Fangrui Song2019-07-181-1/+1
| | | | | | | | | | | -DBUILD_SHARED_LIBS=on link error after D64173/r366361 This fixes: ld.lld: error: undefined symbol: llvm::findAllocaForValue(llvm::Value*, llvm::DenseMap<llvm::Value*, llvm::Alloc aInst*, llvm::DenseMapInfo<llvm::Value*>, llvm::detail::DenseMapPair<llvm::Value*, llvm::AllocaInst*> >&) >>> referenced by AArch64StackTagging.cpp llvm-svn: 366396
* Only build lldb-tblgen if it's not a current targetNathan Lanza2019-07-181-7/+13
| | | | | | | | | | | | | | | Summary: When doing standalone builds, you could potentially be building against an llvm which also built lldb. If this were the case, you'd be attempting to build this target twice. Reviewers: xiaobai Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D64847 llvm-svn: 366394
* [Tests] Add a test showing how we handle overaligned allocas w/ no-realign-stackPhilip Reames2019-07-181-0/+55
| | | | | | (At the moment, we ignore the alignment requirement.) llvm-svn: 366393
* [cmake] Add NATIVE build for cross compiling standalone buildsNathan Lanza2019-07-181-0/+14
| | | | | | | | | TableGen is a host tool and requires a native variant for every build. While building as a part of llvm this is trivial and llvm handles it. However, building standalone means that lldb has to handle this itself. Add a NATIVE build variant to enable this. llvm-svn: 366392
* [analyzer] MallocChecker: Prevent Integer Set Library false positivesCsaba Dabis2019-07-182-1/+75
| | | | | | | | | | | | | | Summary: Integer Set Library using retain-count based allocation which is not modeled in MallocChecker. Reviewed By: NoQ Tags: #clang Differential Revision: https://reviews.llvm.org/D64680 llvm-svn: 366391
* Changes to display code view debug info type records in hex formatNilanjana Basu2019-07-177-122/+149
| | | | llvm-svn: 366390
* hwasan: Use C++ driver for cfi.cc test.Peter Collingbourne2019-07-171-1/+1
| | | | | | | | | | | | | | It turns out that this test was only passing by accident. It was relying on the optimizer to remove the only reference to A's vtable by realizing that the CFI check will always fail. The vtable contains a reference to RTTI in libc++, which will be unresolved because the C driver won't link against it. This was found by my prototype implementation of HWASAN for globals, which happens to end up preserving the reference. Differential Revision: https://reviews.llvm.org/D64890 llvm-svn: 366389
* Make DT a transitive dependency of LI.Evgeniy Stepanov2019-07-171-1/+1
| | | | | | | | | | | | | | | | | | Summary: LoopInfoWrapperPass::verify uses DT, which means DT must be alive even if it has no direct users. Fixes a crash in expensive checks mode. Reviewers: pcc, leonardchan Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64896 llvm-svn: 366388
* [llvm-bcanalyzer] Fixed error 'Expected<T> must be checked before access or ↵Denis Bakhvalov2019-07-171-2/+5
| | | | | | | | | | | | | | | | destruction' After rL365286 I had failing test: LLVM :: tools/gold/X86/v1.12/thinlto_emit_linked_objects.ll It was failing with the output: $ llvm-bcanalyzer --dump llvm/test/tools/gold/X86/v1.12/Output/thinlto_emit_linked_objects.ll.tmp3.o.thinlto.bc Expected<T> must be checked before access or destruction. Unchecked Expected<T> contained error: Unexpected end of file reading 0 of 0 bytesStack dump: Change-Id: I07e03262074ea5e0aae7a8d787d5487c87f914a2 llvm-svn: 366387
* llvm-pdbdump: Fix several smaller issues with injected source compression ↵Nico Weber2019-07-1714-27/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | handling - getCompression() used to return a PDB_SourceCompression even though the docs for IDiaInjectedSource are explicit about the return value being compiler-dependent. Return an uint32_t instead, and make the printing code handle unknown values better by printing "Unknown" and the int value instead of not printing any compression. - Print compressed contents as hex dump, not as string. - Add compression type "DotNet", which is used (at least) by csc.exe, the C# compiler. Also add a lengthy comment describing the stream contents (derived from looking at the raw hex contents long enough to see the GUIDs, which led me to the roslyn and mono implementations for handling this). - The native injected source dumper was dumping the contents of the whole data stream -- but csc.exe writes a stream that's padded with zero bytes to the next 512 boundary, and the dia api doesn't display those padding bytes. So make NativeInjectedSource::getCode() do the same thing. Differential Revision: https://reviews.llvm.org/D64879 llvm-svn: 366386
* [AMDGPU] Simplify AMDGPUInstPrinter::printRegOperand()Stanislav Mekhanoshin2019-07-172-157/+37
| | | | | | Differential Revision: https://reviews.llvm.org/D64892 llvm-svn: 366385
* AMDGPU: Set inaccessiblememonly on sendmsg intrinsicsMatt Arsenault2019-07-171-2/+2
| | | | llvm-svn: 366384
* [NFC] Clarify a Cmake status message regarding Python on LLDBConfigAdrian McCarthy2019-07-171-1/+1
| | | | llvm-svn: 366383
* [X86] Make sure we mark 128/256 MLOAD as Legal with VLX when ↵Craig Topper2019-07-172-5/+20
| | | | | | | | | min-legal-vector-width=256 is in effect. This started triggering an assertion after r364718 when we made these Custom under AVX2. llvm-svn: 366382
* Ah, forgot a debug line I left in the dsym-for-uuid.sh scriptJason Molenda2019-07-171-1/+0
| | | | | | | to make sure it was correctly being disabled after this test case completed. llvm-svn: 366381
* gn build: Merge r366361.Peter Collingbourne2019-07-171-0/+1
| | | | llvm-svn: 366380
* hwasan: Initialize the pass only once.Peter Collingbourne2019-07-175-41/+36
| | | | | | | | | | This will let us instrument globals during initialization. This required making the new PM pass a module pass, which should still provide access to analyses via the ModuleAnalysisManager. Differential Revision: https://reviews.llvm.org/D64843 llvm-svn: 366379
* Add support to ProcessMachCore::DoLoadCore to handle an EFI UUID str.Jason Molenda2019-07-176-0/+497
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a core file has an EFI version string which includes a UUID (similar to what it returns for the kdp KDP_KERNELVERSION packet) in the LC_IDENT or LC_NOTE 'kern ver str' load command. In that case, we should try to find the binary and dSYM for the UUID listed. The dSYM may have python code which knows how to relocate the binary to the correct address in lldb's target section load list and loads other ancillary binaries. The test case is a little involved, 1. it compiles an inferior hello world apple (a.out), 2. it compiles a program which can create a corefile manually with a specific binary's UUID encoded in it, 3. it gets the UUID of the a.out binary, 4. it creates a shell script, dsym-for-uuid.sh, which will return the full path to the a.out + a.out.dSYM when called with teh correct UUID, 5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before creating the lldb target, to point to this dsym-for-uuid.sh, 6. runs the create-corefile binary we compiled in step #2, 7. loads the corefile from step #6 into lldb, 8. verifies that lldb loaded a.out by reading the LC_NOTE load command from the corefile, calling dsym-for-uuid.sh with that UUID, got back the path to a.out and loaded it. whew! <rdar://problem/47562911> llvm-svn: 366378
* [NFC][ScopBuilder] Move buildSchedule and its callees to ScopBuilder or ↵Dominik Adamski2019-07-176-320/+327
| | | | | | | | | | | | | | | | | | ScopHelper Scope of changes: 1. Moved buildSchedule functions to ScopBuilder. 2. Moved combineInSequence function to ScopBuilder. 3. Moved mapToDimension function to ScopBuilder. 4. Moved LoopStackTy to ScopBuilder. 5. Moved getLoopSurroundingScop to ScopHelper. 6. Moved getNumBlocksInLoop to ScopHelper. 7. Moved getNumBlocksInRegionNode to ScopHelper. 8. Moved getRegionNodeLoop to ScopHelper. Differential Revision: https://reviews.llvm.org/D64223 llvm-svn: 366377
* [AMDGPU] Stop special casing flat_scratch for register nameStanislav Mekhanoshin2019-07-172-13/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D64885 llvm-svn: 366376
* Speculative fix for stack-tagging.ll failure.Evgeniy Stepanov2019-07-171-2/+2
| | | | | | | Depending on the evaluation order of function call arguments, the current code may insert a use before def. llvm-svn: 366375
* [NFC][ScopBuilder]Move finalizeAccesses and its callees to ScopBuilderDominik Adamski2019-07-174-253/+259
| | | | | | | | | | | | | | | Scope of changes: 1) Moved finalizeAccesses to ScopBuilder 2) Moved updateAccessDimensionality to ScopBuilder 3) Moved foldSizeConstantsToRight to ScopBuilder 4) Moved foldSizeConstantsToRight to ScopBuilder 5) Moved assumeNoOutOfBounds to ScopBuilder 6) Moved markFortranArrays to ScopBuilder 7) Added iterator range for AccessFunctions vector. Differential Revision: https://reviews.llvm.org/D63794 llvm-svn: 366374
* [Attributor][NFC] Remove unnecessary debug outputHideto Ueno2019-07-171-1/+0
| | | | llvm-svn: 366373
* Adding inline comments to code view type record directives for better ↵Nilanjana Basu2019-07-175-265/+325
| | | | | | readability llvm-svn: 366372
* [PEI] Don't re-allocate a pre-allocated stack protector slotFrancis Visoiu Mistrih2019-07-177-10/+37
| | | | | | | | | | | | | | | | | | | | | | The LocalStackSlotPass pre-allocates a stack protector and makes sure that it comes before the local variables on the stack. We need to make sure that later during PEI we don't re-allocate a new stack protector slot. If that happens, the new stack protector slot will end up being **after** the local variables that it should be protecting. Therefore, we would have two slots assigned for two different stack protectors, one at the top of the stack, and one at the bottom. Since PEI will overwrite the assigned slot for the stack protector, the load that is used to compare the value of the stack protector will use the slot assigned by PEI, which is wrong. For this, we need to check if the object is pre-allocated, and re-use that pre-allocated slot. Differential Revision: https://reviews.llvm.org/D64757 llvm-svn: 366371
* [CodeGen] Add stack protector tests where the guard gets re-assignedFrancis Visoiu Mistrih2019-07-176-0/+134
| | | | | | In preparation of a fix, add tests for multiple backends. llvm-svn: 366370
* [CodeGen][NFC] Simplify checks for stack protector index checkingFrancis Visoiu Mistrih2019-07-172-13/+11
| | | | | | | Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex() >= 0`. llvm-svn: 366369
* Renamed and changed the wording of warn_cconv_ignoredSunil Srivastava2019-07-1717-65/+65
| | | | | | | | As discussed in D64780 the wording of this warning message is being changed to say 'is not supported' instead of 'ignored', and the diag ID itself is being changed to warn_cconv_not_supported. llvm-svn: 366368
* GlobalISel: Handle widenScalar of arbitrary G_MERGE_VALUES sourcesMatt Arsenault2019-07-175-186/+490
| | | | | | | | | | | Extract the sources to the GCD of the original size and target size, padding with implicit_def as necessary. Also fix the case where the requested source type is wider than the original result type. This was ignoring the type, and just using the destination. Do the operation in the requested type and truncate back. llvm-svn: 366367
* GlobalISel: Handle more cases for widenScalar of G_MERGE_VALUESMatt Arsenault2019-07-173-4/+118
| | | | | | | | | | | | Use an anyext to the requested type for the leftover operand to produce a slightly wider type, and then truncate the final merge. I have another implementation almost ready which handles arbitrary widens, but I think it produces worse code in this example (which I think is 90% due to not folding redundant copies or folding out implicit_def users), so I wanted to add this as a baseline first. llvm-svn: 366366
* Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack ↵Shafik Yaghmour2019-07-174-3/+43
| | | | | | | | | | memory In ClangASTContext::CreateFunctionTemplateSpecializationInfo a TemplateArgumentList is allocated on the stack but is treated as if it is persistent in subsequent calls. When we exit the function func_decl will still point to the stack allocated memory. We will use TemplateArgumentList::CreateCopy instead which will allocate memory out of the DeclContext. Differential Revision: https://reviews.llvm.org/D64777 llvm-svn: 366365
* [docs] Adjust variable formatting tableJonas Devlieghere2019-07-171-1/+10
| | | | | | | | | | | | | | While the in-place hints on valid formats are up to date (e.g. when choosing an invalid format expr -f nonExisting -- 42), the corresponding online docs table is not. The formats "address", "hex float", "instruction" and "void" are missing, and "decimal" refers to an outdated abbreviation 'i' instead of 'd'. Patch by: Lukas Böger Differential revision: https://reviews.llvm.org/D63813 llvm-svn: 366364
* [CMake] Remove duplicated logic to find Python when doing a standalone buildJonas Devlieghere2019-07-171-12/+0
| | | | | | | | | | | I'm pretty sure there's no need to have this logic living in LLDBStandalone. It doesn't appear anything in LLVM depends on this, and We always go through LLDBConfig.cmake which has the canonical way to find the Python libs and interpreter for LLDB. Differential revision: https://reviews.llvm.org/D64821 llvm-svn: 366363
OpenPOWER on IntegriCloud