summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] Mark the MLIR tools for installation in CMakeKern Handa2020-02-053-3/+3
| | | | | | | | This binplaces `mlir-translate`, `mlir-cuda-runner`, and `mlir-cpu-runner` when building the CMake install target. Differential Revision: https://reviews.llvm.org/D73986 (cherry picked from commit b8004b7308b490b93231789cd05f86294a77d663)
* PR44786: Don't assert when profiling <=> expressions.Richard Smith2020-02-042-2/+11
| | | | (cherry picked from commit b96c6b65b93f7b3878bced2374bef747a4c3b690)
* [Concepts] Add missing CXXThisScope to function template constraint substitutionSaar Raz2020-02-053-2/+24
| | | | | | | | | | We did not have a CXXThisScope around constraint checking of functions and function template specializations, causing a crash when checking a constraint that had a 'this' (bug 44689). Recommit after fixing test. (cherry picked from commit 6c232441564f8934477e418347bf0c217abb0a00)
* PR44721: Don't consider overloaded operators for built-in comparisonsRichard Smith2020-02-042-7/+34
| | | | | | | | | | | | | | | | | | | | when building a defaulted comparison. As a convenient way of asking whether `x @ y` is valid and building it, we previouly always performed overload resolution and built an overloaded expression, which would both end up picking a builtin operator candidate when given a non-overloadable type. But that's not quite right, because it can result in our finding a user-declared operator overload, which we should never do when applying operators non-overloadable types. Handle this more correctly: skip overload resolution when building `x @ y` if the operands are not overloadable. But still perform overload resolution (considering only builtin candidates) when checking validity, as we don't have any other good way to ask whether a binary operator expression would be valid. (cherry picked from commit 1f3f8c369a5067a132c871f33a955a7feaea8534)
* PR44761: Fix fallback to later tiebreakers if two non-template functionsRichard Smith2020-02-042-8/+22
| | | | | | are equally constrained. (cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
* Add -Wrange-loop-analysis changes to ReleaseNotesMark de Wever2020-02-041-1/+3
| | | | | | This reflects the recent changes done. Differential Revision: https://reviews.llvm.org/D73834
* [libcxx] [Windows] Store the lconv struct returned from localeconv in locale_tMartin Storsjö2020-02-042-7/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes using non-default locales, which currently can crash when e.g. formatting numbers. Within the localeconv_l function, the per-thread locale is temporarily changed with __libcpp_locale_guard, then localeconv() is called, returning an lconv * struct pointer. When localeconv_l returns, the __libcpp_locale_guard dtor restores the per-thread locale back to the original. This invalidates the contents of the earlier returned lconv struct, and all C strings that are pointed to within it are also invalidated. Thus, to have an actually working localeconv_l function, the function needs to allocate some sort of storage for the returned contents, that stays valid for as long as the caller needs to use the returned struct. Extend the libcxx/win32 specific locale_t class with storage for a deep copy of a lconv struct, and change localeconv_l to take a reference to the locale_t, to allow it to store the returned lconv struct there. This works fine for libcxx itself, but wouldn't necessarily be right for a caller that uses libcxx's localeconv_l function. This fixes around 11 of libcxx's currently failing tests on windows. Differential Revision: https://reviews.llvm.org/D69505 (cherry picked from commit 7db4f2c6945a24a7d81dad3362700353e2ec369e)
* AMDGPU: Fix handling of infinite loops in fragment shadersConnor Abbott2020-02-042-6/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Due to the fact that kill is just a normal intrinsic, even though it's supposed to terminate the thread, we can end up with provably infinite loops that are actually supposed to end successfully. The AMDGPUUnifyDivergentExitNodes pass breaks up these loops, but because there's no obvious place to make the loop branch to, it just makes it return immediately, which skips the exports that are supposed to happen at the end and hangs the GPU if all the threads end up being killed. While it would be nice if the fact that kill terminates the thread were modeled in the IR, I think that the structurizer as-is would make a mess if we did that when the kill is inside control flow. For now, we just add a null export at the end to make sure that it always exports something, which fixes the immediate problem without penalizing the more common case. This means that we sometimes do two "done" exports when only some of the threads enter the discard loop, but from tests the hardware seems ok with that. This fixes dEQP-VK.graphicsfuzz.while-inside-switch with radv. Reviewers: arsenm, nhaehnle Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70781 (cherry picked from commit 87d98c149504f9b0751189744472d7cc94883960)
* [LLD][ELF][ARM][AArch64] Only round up ThunkSection Size when large OS.Peter Smith2020-02-047-23/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In D71281 a fix was put in to round up the size of a ThunkSection to the nearest 4KiB when performing errata patching. This fixed a problem with a very large instrumented program that had thunks and patches mutually trigger each other. Unfortunately it triggers an assertion failure in an AArch64 allyesconfig build of the kernel. There is a specific assertion preventing an InputSectionDescription being larger than 4KiB. This will always trigger if there is at least one Thunk needed in that InputSectionDescription, which is possible for an allyesconfig build. Abstractly the problem case is: .text : { *(.text) ; ... . = ALIGN(SZ_4K); __idmap_text_start = .; *(.idmap.text) __idmap_text_end = .; ... } The assertion checks that __idmap_text_end - __idmap_start is < 4 KiB. Note that there is more than one InputSectionDescription in the OutputSection so we can't just restrict the fix to OutputSections smaller than 4 KiB. The fix presented here limits the D71281 to InputSectionDescriptions that meet the following conditions: 1.) The OutputSection is bigger than the thunkSectionSpacing so adding thunks will affect the addresses of following code. 2.) The InputSectionDescription is larger than 4 KiB. This will prevent any assertion failures that an InputSectionDescription is < 4 KiB in size. We do this at ThunkSection creation time as at this point we know that the addresses are stable and up to date prior to adding the thunks as assignAddresses() will have been called immediately prior to thunk generation. The fix reverts the two tests affected by D71281 to their original state as they no longer need the 4KiB size roundup. I've added simpler tests to check for D71281 when the OutputSection size is larger than the ThunkSection spacing. Fixes https://github.com/ClangBuiltLinux/linux/issues/812 Differential Revision: https://reviews.llvm.org/D72344 (cherry picked from commit 01ad4c838466bd5db180608050ed8ccb3b62d136)
* [ELF] Decrease alignment of ThunkSection on 64-bit targets from 8 to 4Fangrui Song2020-02-0411-58/+58
| | | | | | | | | | | | | ThunkSection contains 4-byte instructions on all targets that use thunks. Thunks should not be used in any performance sensitive places, and locality/cache line/instruction fetching arguments should not apply. We use 16 bytes as preferred function alignments for modern PowerPC cores. In any case, 8 is not optimal. Differential Revision: https://reviews.llvm.org/D72819 (cherry picked from commit 870094decfc9fe80c8e0a6405421b7d09b97b02b)
* [libcxxabi] Fix layout of __cxa_exception for win64Martin Storsjö2020-02-041-5/+5
| | | | | | | | | | | | Win64 isn't LP64, it's LLP64, but there's no __LLP64__ predefined - just check _WIN64 in addition to __LP64__. This fixes compilation after static asserts about the struct layout were added in f2a436058fcbc11291e73badb44e243f61046183. Differential Revision: https://reviews.llvm.org/D73838 (cherry picked from commit 09dc884eb2e4a433eb8c5ed20a17108091279295)
* Actually, don't try to use __builtin_strlen in StringRef.h before VS 2019Hans Wennborg2020-02-031-2/+3
| | | | | | | | | The fix in b3d7d1061dc375bb5ea725e6597382fcd37f41d6 compiled nicely, but didn't link because at least the VS 2017 version I use doesn't have the builtin yet. Instead, make use of the builtin with MSVC conditional on VS 2019 or later. (cherry picked from commit ff837aa63cdfadb58f387ca77785ca3ca51c6976)
* Declare __builtin_strlen in StringRef.h as constexprHans Wennborg2020-02-031-1/+1
| | | | | | | | | | Otherwise Visual Studio 2017 will complain about llvm::StringRef::strlen not being constexpr: StringRef.h(80): error C3615: constexpr function 'llvm::StringRef::strLen' cannot result in a constant expression StringRef.h(84): note: failure was caused by call of undefined function or one not declared 'constexpr' (cherry picked from commit b3d7d1061dc375bb5ea725e6597382fcd37f41d6)
* [clang-tidy] Fixed crash 44745 in readability-else-after-returnNathan James2020-02-032-0/+17
| | | | | | | | | | | | | | | | Summary: Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44745 | readability-else-after-return crashes ]] Reviewers: aaron.ballman, alexfh, hokein, JonasToth, gribozavr2 Reviewed By: alexfh Subscribers: merge_guards_bot, xazax.hun, cfe-commits Tags: #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D73841 (cherry picked from commit d591bdce6d623208d4aeb335a762d839f0f8f0f7)
* R600: Fix failing testcaseMatt Arsenault2020-02-031-3/+3
| | | | (cherry picked from commit 7dc49f77ee508b4152f9291c8e804e4eda3653d3)
* AMDGPU/R600: Emit rodata in text segmentJan Vesely2020-02-032-1/+7
| | | | | | | | | | R600 relies on this behaviour. Fixes: 6e18266aa4dd78953557b8614cb9ff260bad7c65 ('Partially revert D61491 "AMDGPU: Be explicit about whether the high-word in SI_PC_ADD_REL_OFFSET is 0"') Fixes ~100 piglit regressions since 6e18266 Differential Revision: https://reviews.llvm.org/D72991 (cherry picked from commit 1b8eab179db46f25a267bb73c657009c0bb542cc)
* [BPF] fix a bug in BPFMISimplifyPatchable pass with -O0Yonghong Song2020-02-032-3/+56
| | | | | | | | | | | | | | | | | | | | The recommended optimization level for BPF programs is O2 since (1). BPF is running inside the kernel and linux kernel won't work at -O0 level, and (2). Verifier is not able to handle O0 code properly, e.g., potential large stack size and a lot of spills. But we should keep -O0 at least compiling. This patch fixed a bug in BPFMISimplifyPatchable phase where with -O0, a segmentation fault will happen for a simple program like: int test(int a, int b) { return a + b; } A test case is added to capture such a case. Differential Revision: https://reviews.llvm.org/D73681 (cherry picked from commit 795bbb366266e83d2bea8dc04c19919b52ab3a2a)
* Revert "[AMDGPU] Invert the handling of skip insertion."Nicolai Hähnle2020-02-0340-390/+380
| | | | | | | | | This reverts commit 0dc6c249bffac9f23a605ce4e42a84341da3ddbd. The commit is reported to cause a regression in piglit/bin/glsl-vs-loop for Mesa. (cherry picked from commit a80291ce10ba9667352adcc895f9668144f5f616)
* [RISCV] Scheduler description for the Rocket coreKai Wang2020-02-0311-186/+900
| | | | | | | | | | Pipeline scheduler model for the RISC-V Rocket micro-architecture using the MIScheduler interface. Support for both 32 and 64-bit Rocket cores is implemented. Differential revision: https://reviews.llvm.org/D68685 (cherry picked from commit 838a28e234e098bfc073a45f37a4dd3bb5b45eab)
* [Concepts] Instantiate invented template type parameter type-constraint ↵Saar Raz2020-02-033-20/+184
| | | | | | | | | | | | | | | | | along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time. (cherry picked from commit 84959ae47f447fca9d56a9c61e8c46e993d0387a)
* Revert "[Concepts] Instantiate invented template type parameter ↵Saar Raz2020-02-033-179/+20
| | | | | | type-constraint along with function parameters" This temporarily reverts commit 2b54b8b994b45d4e0a72f36dfb91dc9662543234 which caused some test failures.
* [Concepts] Instantiate invented template type parameter type-constraint ↵Saar Raz2020-02-033-20/+179
| | | | | | | | | | | | | | along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. (cherry picked from commit eacca4824463d8b96e2e1c9f8bbf886055218a16)
* [libcxxabi] Insert padding in __cxa_exception struct for compatibilitySteven Wu2020-02-031-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Preserve the old ABI for __cxa_exception and __cxa_dependent_exception on 64 bit platforms or ARM_EHABI platforms. After r276215, libunwind in llvm-project labels _Unwind_Exception to be double word aligned. That change implictly adds a padding before unwindHeader field in __cxa_exception and __cxa_dependent_exception. Preserve the same negative offsets in those struct by moving the padding to the beginning of the field. The assumption here is that if the ABI is not aware of the padding before unwindHeader and put the referenceCount/primaryException in there, no padding should exist before unwindHeader. Reviewers: EricWF, mclow.lists, ldionne, jroelofs, dexonsmith, rjmccall, compnerd, phosek, ahatanak Reviewed By: rjmccall Subscribers: hans, smeenai, kristof.beyls, christof, jkorous, ributzka, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D72543 (cherry picked from commit f2a436058fcbc11291e73badb44e243f61046183)
* [AArch64] -fpatchable-function-entry=N,0: place patch label after BTIFangrui Song2020-02-034-4/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For -fpatchable-function-entry=N,0 -mbranch-protection=bti, after 9a24488cb67a90f889529987275c5e411ce01dda, we place the NOP sled after the initial BTI. ``` .Lfunc_begin0: bti c nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lfunc_begin0 ``` This patch adds a label after the initial BTI and changes the __patchable_function_entries entry to reference the label: ``` .Lfunc_begin0: bti c .Lpatch0: nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lpatch0 ``` This placement is compatible with the resolution in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 . A local linkage function whose address is not taken does not need a BTI. Placing the patch label after BTI has the advantage that code does not need to differentiate whether the function has an initial BTI. Reviewers: mrutland, nickdesaulniers, nsz, ostannard Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73680 (cherry picked from commit 06b8e32d4fd3f634f793e3bc0bc4fdb885e7a3ac)
* MSVC Buggy version detection: turn pre-processor error into CMake ↵Mehdi Amini2020-02-031-0/+14
| | | | | | | | | | | | | | | | | configuration time check This allows consumer to override in a cleaner way while still prevent them from hitting bug without knowing they run an unsupported configuration. Recommit after fix by Christopher Tetreault to add parens and ${} to cmake check to work around CMake configure time "unknown arguments specified" issue Differential Revision: https://reviews.llvm.org/D73677 Differential Revision: https://reviews.llvm.org/D73751 (cherry picked from commit 5f940220bf9438e95ffa4a627ac1591be1e1ba6e)
* [Sema] Remove a -Wrange warning from -WallMark de Wever2020-02-034-9/+12
| | | | | | | | | | | | | | | | | | | | | | | During the review of D73007 Aaron Puchert mentioned `warn_for_range_variable_always_copy` shouldn't be part of -Wall since some coding styles require `for(const auto &bar : bars)`. This warning would cause false positives for these users. Based on Aaron's proposal refactored the warnings: * -Wrange-loop-construct warns about possibly unintended constructor calls. This is part of -Wall. It contains * warn_for_range_copy: loop variable A of type B creates a copy from type C * warn_for_range_const_reference_copy: loop variable A is initialized with a value of a different type resulting in a copy * -Wrange-loop-bind-reference warns about misleading use of reference types. This is not part of -Wall. It contains * warn_for_range_variable_always_copy: loop variable A is always a copy because the range of type B does not return a reference Differential Revision: https://reviews.llvm.org/D73434 (cherry picked from commit c03349e40f21f0375278138992a32694a99c830e)
* Make quick-append.test resilient to running in paths with '1.o' in the nameHans Wennborg2020-02-031-9/+9
| | | | (cherry picked from commit f00ab188f4e4214dfbecfdd8968a183e9363cefa)
* Fix wrong devirtualization when the final overrider in one base classRichard Smith2020-01-313-4/+73
| | | | | | overrides the final overrider in a different base class. (cherry picked from commit aade5fbbfef3e8555df202082bea905deebc2ca5)
* PR44723: Trigger return type deduction for operator<=>s whose returnRichard Smith2020-01-313-0/+64
| | | | | | | | | | types are needed to compute the return type of a defaulted operator<=>. This raises the question of what to do if return type deduction fails. The standard doesn't say, and implementations vary, so for now reject that case eagerly to keep our options open. (cherry picked from commit 42d4a55f227a1cc78ab8071062d869abe88655d9)
* [Concepts] Fix isDeclarationSpecifier to detect type-constraints correctlySaar Raz2020-01-312-11/+41
| | | | | | | | | isDeclarationSpecifiers did not handle some cases of placeholder-type-specifiers with type-constraints, causing parsing bugs in abbreviated constructor templates. Add comprehensive handling of type-constraints to isDeclarationSpecifier. (cherry picked from commit b7ce85a130789d23c69156f4b899962458d1f05d)
* [Concepts] Correctly form initial parameter mapping for parameter packs, ↵Saar Raz2020-01-317-26/+136
| | | | | | | | | | | | support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent). (cherry picked from commit ba1f3db4b0729ad932aa4f091e9578132d98a0c8)
* Revert "[libcxx] Force-cache LIBCXX_CXX_ABI_LIBRARY_PATH"Sergej Jaskiewicz2020-01-311-1/+1
| | | | | | This reverts commit 41f4dfd63ea0fe995ddfba1838aa5ed972cc1377. It broke standalone libc++ builds, which now try to use libc++abi from the wrong directory, instead of system instance.
* PR44627: Consider reversing == and <=> candidates found by ADL.Richard Smith2020-01-303-9/+35
| | | | (cherry picked from commit 1db66e705f4dbe7dbe17edac804289ef59d5f616)
* [Concepts] Check function constraints before deducing auto return typeSaar Raz2020-01-312-24/+27
| | | | | | | | | | A constrained function with an auto return type would have it's definition instantiated in order to deduce the auto return type before the constraints are checked. Move the constraints check after the return type deduction. (cherry picked from commit 980517b3530ffb7faa1a23fdc007d78f5b45ae3c)
* PR41991: Accept attributes on defaulted and deleted friends.Richard Smith2020-01-303-1/+11
| | | | | | | Attributes are permitted on friend definitions, but we only checked for a proper function body, not for the =default / =delete cases. (cherry picked from commit 5ae6554a1dcd2e39346030c06d364492901c9e8d)
* [Concepts] Add 'this' context to instantiation of member requires clauseSaar Raz2020-01-301-0/+3
| | | | | | 'this' context was missing in instantiation of member requires clause. (cherry picked from commit 60f5da79e3de49b2074446e656a72970499a8d78)
* [Concepts] Add check for dependent RC when checking function constraintsSaar Raz2020-01-302-7/+6
| | | | | | | Do not attempt to check a dependent requires clause in a function constraint (may be triggered by, for example, DiagnoseUseOfDecl). (cherry picked from commit a424ef99e7b9821ec80564af3d3a8f091323a38c)
* [Concept] Fix incorrect check for containsUnexpandedParameterPack in CSESaar Raz2020-01-304-21/+78
| | | | | | | | | | We previously checked for containsUnexpandedParameterPack in CSEs by observing the property in the converted arguments of the CSE. This may not work if the argument is an expanded type-alias that contains a pack-expansion (see added test). Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent. (cherry picked from commit c83d9bedc0cc430dc620e7a807daeb985d390325)
* Generate docsHans Wennborg2020-01-303-938/+9528
| | | | | | | | | | | | | | bin/clang-tblgen -gen-diag-docs -I../clang/include \ -I../clang/include/clang/Basic/ \ ../clang/include/clang/Basic/Diagnostic.td -o \ ../clang/docs/DiagnosticsReference.rst && \ bin/clang-tblgen -gen-attr-docs -I../clang/include \ ../clang/include/clang/Basic/Attr.td -o \ ../clang/docs/AttributeReference.rst && \ bin/clang-tblgen -gen-opt-docs -I../clang/include \ -I../clang/include/clang/Driver -I../llvm/include \ ../clang/include/clang/Driver/ClangOptionDocs.td -o \ ../clang/docs/ClangCommandLineReference.rst
* Define _LIBCPP_HAS_TIMESPEC_GET for FreeBSD when appropriateDimitry Andric2020-01-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: FreeBSD got `timespec_get` support somewhere in the 12.x timeframe, but the C++ version check in its system headers was written incorrectly. This has now been fixed for both FreeBSD 13 and 12. Add checks for the corresponding `__FreeBSD_version` values, to define `_LIBCPP_HAS_TIMESPEC_GET` when the function is supported. Reviewers: emaste, EricWF, ldionne, mclow.lists Reviewed By: ldionne Subscribers: arichardson, krytarowski, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71522 (cherry picked from commit 5e416ba943b7c737deb8eca62756f7b4fa925845)
* Drop arm triple from test/CodeGen/AArch64/global-merge-hidden-minsize.llHans Wennborg2020-01-301-1/+0
| | | | | | | Because it's in the AArch64/ directory, it runs in cases where the arm target may not be available, see comment on D73235. (cherry picked from commit 6be9acdfa814dee6c57833d5351137c72c11fbd3)
* test-release.sh: Add MLIR to the projects listHans Wennborg2020-01-301-0/+8
| | | | (cherry picked from commit ef465d0ad2b98cae6fd6f6c450649f40e67fa24b)
* [mlir][orc] unbreak MLIR ExecutionEngine after ORC changesAlex Zinenko2020-01-301-3/+3
| | | | | | | | | | Changes to ORC in ce2207abaf9a925b35f15ef92aaff6b301ba6d22 changed the APIs in IRCompileLayer, now requiring the custom compiler to be wrapped in IRCompileLayer::IRCompiler. Even though MLIR relies on Orc CompileUtils, the type is still visible in several places in the code. Adapt those to the new API. (cherry picked from commit 7984b47401f7f36475619abf2ff02de3b5ff0481)
* Revert "Reland: [DWARF] Allow cross-CU references of subprogram definitions"Vedant Kumar2020-01-298-295/+24
| | | | | | | | | | | | | | | ... as well as: Revert "[DWARF] Defer creating declaration DIEs until we prepare call site info" This reverts commit fa4701e1979553c2df61698ac1ac212627630442. This reverts commit 79daafc90308787b52a5d3a7586e82acd5e374b3. There have been reports of this assert getting hit: CalleeDIE && "Could not find DIE for call site entry origin (cherry picked from commit 802bec896171997a7b73dde3857712e0eedeabc1)
* [clangd] Don't mmap source files on all platforms --> don't crash on git ↵Sam McCall2020-01-292-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | checkout Summary: Previously we mmapped on unix and not on windows: on windows mmap takes an exclusive lock on the file and prevents the user saving changes! The failure mode on linux is a bit more subtle: if the file is changed on disk but the SourceManager sticks around, then subsequent operations on the SourceManager will fail as invariants are violated (e.g. null-termination). This commonly manifests as crashes after switching git branches with many files open in clangd. Nominally mmap is for performance here, and we should be willing to give some up to stop crashing. Measurements on my system (linux+desktop+SSD) at least show no measurable regression on an a fairly IO-heavy workload: drop disk caches, open SemaOverload.cpp, wait for first diagnostics. for i in `seq 100`; do for variant in mmap volatile; do echo 3 | sudo tee /proc/sys/vm/drop_caches /usr/bin/time --append --quiet -o ~/timings -f "%C %E" \ bin/clangd.$variant -sync -background-index=0 < /tmp/mirror > /dev/null done done bin/clangd.mmap -sync -background-index=0 0:07.60 bin/clangd.volatile -sync -background-index=0 0:07.89 bin/clangd.mmap -sync -background-index=0 0:07.44 bin/clangd.volatile -sync -background-index=0 0:07.89 bin/clangd.mmap -sync -background-index=0 0:07.42 bin/clangd.volatile -sync -background-index=0 0:07.50 bin/clangd.mmap -sync -background-index=0 0:07.90 bin/clangd.volatile -sync -background-index=0 0:07.53 bin/clangd.mmap -sync -background-index=0 0:07.64 bin/clangd.volatile -sync -background-index=0 0:07.55 bin/clangd.mmap -sync -background-index=0 0:07.75 bin/clangd.volatile -sync -background-index=0 0:07.47 bin/clangd.mmap -sync -background-index=0 0:07.90 bin/clangd.volatile -sync -background-index=0 0:07.50 bin/clangd.mmap -sync -background-index=0 0:07.81 bin/clangd.volatile -sync -background-index=0 0:07.95 bin/clangd.mmap -sync -background-index=0 0:07.55 bin/clangd.volatile -sync -background-index=0 0:07.65 bin/clangd.mmap -sync -background-index=0 0:08.15 bin/clangd.volatile -sync -background-index=0 0:07.54 bin/clangd.mmap -sync -background-index=0 0:07.78 bin/clangd.volatile -sync -background-index=0 0:07.61 bin/clangd.mmap -sync -background-index=0 0:07.78 bin/clangd.volatile -sync -background-index=0 0:07.55 bin/clangd.mmap -sync -background-index=0 0:07.41 bin/clangd.volatile -sync -background-index=0 0:07.40 bin/clangd.mmap -sync -background-index=0 0:07.54 bin/clangd.volatile -sync -background-index=0 0:07.42 bin/clangd.mmap -sync -background-index=0 0:07.45 bin/clangd.volatile -sync -background-index=0 0:07.49 bin/clangd.mmap -sync -background-index=0 0:07.95 bin/clangd.volatile -sync -background-index=0 0:07.66 bin/clangd.mmap -sync -background-index=0 0:08.04 Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73617 (cherry picked from commit b500c49cd4f81f067cda721049cb1fd72a5e7bf5)
* [LV] Do not try to sink dead instructions.Florian Hahn2020-01-293-8/+51
| | | | | | | | | | | | | | | | | Dead instructions do not need to be sunk. Currently we try and record the recipies for them, but there are no recipes emitted for them and there's nothing to sink. They can be removed from SinkAfter while marking them for recording. Fixes PR44634. Reviewers: rengolin, hsaito, fhahn, Ayal, gilr Reviewed By: gilr Differential Revision: https://reviews.llvm.org/D73423 (cherry picked from commit a911fef3dd79e0a04b241be7b476dde7e99744c4)
* [clan-tidy] Fix false positive in bugprone-infinite-loopAdam Balogh2020-01-292-5/+57
| | | | | | | | | | | | | | The checker bugprone-infinite-loop does not track changes of variables in the initialization expression of a variable declared inside the condition of the while statement. This leads to false positives, similarly to the one in the bug report https://bugs.llvm.org/show_bug.cgi?id=44618. This patch fixes this issue by enabling tracking of the variables of this expression as well. Differential Revision: https://reviews.llvm.org/D73270 (cherry picked from commit 70f4c6e7b14f225f9628fbdab3620ce037613351)
* [WebAssembly] Fix resume-only case in Emscripten EHHeejin Ahn2020-01-293-26/+21
| | | | | | | | | | | | | | | | | | Summary: D72308 incorrectly assumed `resume` cannot exist without a `landingpad`, which is not true. This sets `Changed` to true whenever we make changes to a function, including creating a call to `__resumeException` within a function without a landing pad. Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73308 (cherry picked from commit 580d7838dd08e13dac6caf4ab3142c9381bc7ad0)
* [ORC] Fix the LLJITWithObjectCache example to address changes in ce2207abaf9.Lang Hames2020-01-291-4/+4
| | | | (cherry picked from commit 97d000da2e6025600c4709d611e853eb1d5d407c)
* Update clang-interpreter example to incorporate changes in ce2207abaf9.Lang Hames2020-01-291-1/+2
| | | | (cherry picked from commit b54aa053d3aeeab0cdaecb6286419138b7da5ef4)
OpenPOWER on IntegriCloud