summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert rL368939 "Remove LVALUE / RVALUE workarounds"Russell Gallop2019-08-154-11/+40
| | | | | | | | This reverts commit cad8356d699b36c73abb267f65db575ddacbd652. To unbreak Windows bots llvm-svn: 368985
* [Support] Fix Wundef warningSven van Haastregt2019-08-151-0/+2
| | | | llvm-svn: 368984
* [ELF][AArch64] Improve error message for unknown relocationsFangrui Song2019-08-152-2/+55
| | | | | | | | | | | | | | | | | | | | Like rLLD354040. Previously, for unrecognized relocation types, in -no-pie/-pie mode, we got something like: foo.o: unrecognized relocation ... In -shared mode: error: can't create dynamic relocation ... against symbol: yyy in readonly segment Delete the default case from AArch64::getRelExpr and add the error there. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D66277 llvm-svn: 368983
* [llvm-objcopy] Allow 'protected' visibility to be set when usingChris Jackson2019-08-154-6/+10
| | | | | | | | | | add-symbol Reviewers: Maskray, rupprecht Differential Revision: https://reviews.llvm.org/D65891 llvm-svn: 368982
* [ARM] MVE trunc to i1 vectorsDavid Green2019-08-152-0/+68
| | | | | | | | | This adds patterns for selecting trunc instructions from full vectors to i1's vectors. Differential Revision: https://reviews.llvm.org/D66201 llvm-svn: 368981
* [analyzer] Warn about -analyzer-configs being meant for development purposes ↵Kristof Umann2019-08-152-6/+18
| | | | | | | | | | | | only This is more of a temporary fix, long term, we should convert AnalyzerOptions.def into the universally beloved (*coughs*) TableGen format, where they can more easily be separated into developer-only, alpha, and user-facing configs. Differential Revision: https://reviews.llvm.org/D66261 llvm-svn: 368980
* [analyzer] Add docs for cplusplus.InnerPointerKristof Umann2019-08-151-2/+27
| | | | | | Differential Revision: https://reviews.llvm.org/D60281 llvm-svn: 368979
* [InstCombine] Precommit test case for D66216Florian Hahn2019-08-151-0/+99
| | | | llvm-svn: 368978
* MemoryBuffer: Add a missing error-check to getOpenFileImplPavel Labath2019-08-152-1/+54
| | | | | | | | | | | | | | | | | | | Summary: In case the function was called with a desired read size *and* the file was not an "mmap()" candidate, the function was falling back to a "pread()", but it was failing to check the result of that system call. This meant that the function would return "success" even though the read operation failed, and it returned a buffer full of uninitialized memory. Reviewers: rnk, dblaikie Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66224 llvm-svn: 368977
* [clang] Loop pragma parsing. NFC.Sjoerd Meijer2019-08-151-18/+13
| | | | | | | | Just a refactoring and a tidy up. Differential Revision: https://reviews.llvm.org/D64564 llvm-svn: 368976
* [lldb] Let LLDB depend on intrinsics_gen to fix non-deterministic module ↵Raphael Isemann2019-08-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | build failures Summary: When building with modules we currently fail randomly to build LLDB's modules and get error messages like below: ``` In file included from <module-includes>:1: In file included from llvm-project/llvm/include/llvm/IR/Argument.h:18: llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found #include "llvm/IR/Attributes.inc" ^~~~~~~~~~~~~~~~~~~~~~~~ ... In file included from llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:9: llvm-project/lldb/source/Plugins/ABI/SysV-arm/ABISysV_arm.h:12:10: fatal error: could not build module 'lldb_Wrapper' ``` The reason for this is that our source files can include Clang headers which in turn include files like Attributes.inc which are generated by intrinsics_gen. However, it seems Clang can't express this dependency in its CMake code, so intrinsics_gen is actually not guaranteed to be built before we start parsing LLDB source files and Clang headers. Clang worked around this by letting all libraries depend on intrinsics_gen, which at least lets their builds pass. As I haven't figured out how to solve these dependencies properly and I want to get the LLDB+Modules build green, I suggest we copy Clang's hack until we figure out how to get Clang's dependencies right. Reviewers: sgraenitz, aprantl, JDevlieghere Reviewed By: JDevlieghere Subscribers: mgorny, javed.absar, kristof.beyls, mgrang, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66208 llvm-svn: 368975
* [llvm-readobj][MachO] Fix section type printingSeiya Nuta2019-08-1555-257/+596
| | | | | | | | | | | | | | | | | | | Summary: Currently, llvm-readobj mistakenly decodes section type as section attribute. This patch fixes the bug and affected tests. Reviewers: JDevlieghere, jhenderson, rupprecht, alexshap, echristo Reviewed By: jhenderson, rupprecht, alexshap, echristo Subscribers: javed.absar, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66075 llvm-svn: 368974
* [LV] fold-tail predication should be respected even with assume_safetyDorit Nuzman2019-08-155-21/+194
| | | | | | | | | | | | | | | assume_safety implies that loads under "if's" can be safely executed speculatively (unguarded, unmasked). However this assumption holds only for the original user "if's", not those introduced by the compiler, such as the fold-tail "if" that guards us from loading beyond the original loop trip-count. Currently the combination of fold-tail and assume-safety pragmas results in ignoring the fold-tail predicate that guards the loads, generating unmasked loads. This patch fixes this behavior. Differential Revision: https://reviews.llvm.org/D66106 Reviewers: Ayal, hsaito, fhahn llvm-svn: 368973
* [X86] Add isel pattern to match VZEXT_MOVL and a v2i64 scalar_to_vector ↵Craig Topper2019-08-152-2/+5
| | | | | | | | | bitcasted from x86mmx to MOVQ2DQ. We already had the pattern for just the scalar to vector and bitcast, but not the case where we wanted zeroes in the high half of the xmm. llvm-svn: 368972
* [X86] Make sure load is non-volatile in the MMX_X86movdq2q (loadv2i64) isel ↵Craig Topper2019-08-151-1/+1
| | | | | | | | | pattern. This pattern will narrow the load so we should make sure its not volatile. llvm-svn: 368971
* [Clang] Pragma vectorize_predicate implies vectorizeSjoerd Meijer2019-08-152-6/+56
| | | | | | | | | | New pragma "vectorize_predicate(enable)" now implies "vectorize(enable)", and it is ignored when vectorization is disabled with e.g. "vectorize(disable) vectorize_predicate(enable)". Differential Revision: https://reviews.llvm.org/D65776 llvm-svn: 368970
* [X86] Add test cases for _mm_movepi64_pi64 and _mm_movpi64_epi64.Craig Topper2019-08-151-0/+17
| | | | llvm-svn: 368969
* [X86] Remove unneeded isel pattern for v4f32->v4i32 fp_to_sint and ↵Craig Topper2019-08-151-3/+0
| | | | | | | | | | conversion to MMX. fp_to_sint is turned into X86cvttp2si during isel preprocessing. The other redundant isel patterns were removed previously, but I missed this one because its in the MMX td file. llvm-svn: 368968
* [X86] Disable custom type legalization for v2i32/v4i16/v8i8->i64.Craig Topper2019-08-151-2/+1
| | | | | | The default legalization can take care of this. llvm-svn: 368967
* [X86] Disable custom type legalization for v2i32/v4i16/v8i8->f64 bitcast.Craig Topper2019-08-151-1/+2
| | | | | | | The generic legalization handles this in the same way so just use that. llvm-svn: 368966
* [X86] Remove some unreachable code from LowerBITCAST.Craig Topper2019-08-151-42/+26
| | | | llvm-svn: 368965
* [ELF][PPC] Improve error message for unknown relocationsFangrui Song2019-08-152-4/+30
| | | | | | | | | | | | | | Like rLLD354040. Previously, for unrecognized relocation types, in -no-pie mode: foo.o: unrecognized reloc 256 In -pie/-shared mode: error: can't create dynamic relocation R_PPC_xxx against symbol: yyy in readonly segment llvm-svn: 368964
* [llvm-objdump] Add warning messages if disassembly + source for problematic ↵Michael Pozulp2019-08-1510-50/+81
| | | | | | | | | | | | | | | | | | inputs Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41905 Reviewers: jhenderson, rupprecht, grimar Reviewed By: jhenderson, grimar Subscribers: RKSimon, MaskRay, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62462 llvm-svn: 368963
* Fix variable mismatch between signature and bodyJonas Devlieghere2019-08-151-3/+3
| | | | | | | I updated the signature to conform to the LLDB coding style but accidentally forgot to update the function body. llvm-svn: 368962
* [llvm-objcopy] Move duplicate tablegen from objcopy and strip into one fileMichael Pozulp2019-08-153-191/+155
| | | | | | | | | | | | | | | | Summary: This avoids maintaining the same options in two different places. Reviewers: jhenderson, alexshap, rupprecht, MaskRay Reviewed By: jhenderson, rupprecht, MaskRay Subscribers: MaskRay, wolfgangp, jakehehrlich, abrachet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65991 llvm-svn: 368961
* [CMake] Check for C++14 instead of C++11Jonas Devlieghere2019-08-152-2/+2
| | | | | | | | | | | | | | | Now that LLVM moved to C++14, `COMPILER_RT_HAS_STD_CXX11_FLAG` should become `COMPILER_RT_HAS_STD_CXX14_FLAG`. I ran into this issue when replacing llvm::make_unique with std::make_unique in an X-ray unit test. We are correctly passing `-std=c++14`, but this got overwritten further down the invocation by the compiler-rt flags. Given that this unit test is using LLVM headers, this is bound to break sooner than later, regardless of my change. Differential revision: https://reviews.llvm.org/D66271 llvm-svn: 368960
* [NFC] Fix documentation for some utility classes.Jonas Devlieghere2019-08-153-32/+25
| | | | | | This fixes a few warnings emitted when compiling with -Wdocumentation. llvm-svn: 368959
* [Tooling] Add a hack to work around issues with matcher binding in r368681.David L. Jones2019-08-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | The change in r368681 contains a (probably unintentional) behavioral change for rewrite rules with a single matcher. Previously, the single matcher would not need to be bound (`joinCaseMatchers` returned it directly), even though a final DynTypeMatcher was created and bound by `buildMatcher`. With the new change, a single matcher will be bound, in addition to the final binding (which is now in `buildMatchers`, but happens roughly at the same point in the overall flow). This patch simply duplicates the "final matcher" trick: it creates an extra DynTypedMatcher for each rewrite rule case matcher, and unconditionally makes it bindable. This is probably not the right long-term fix, but it does allow existing code to continue to work with this interface. Subscribers: cfe-commits, gribozavr, ymandel Tags: #clang Differential Revision: https://reviews.llvm.org/D66273 llvm-svn: 368958
* [NFC] Remove documentation comment to fix warning.Jonas Devlieghere2019-08-151-1/+0
| | | | | | | Remove the @return to fix the warning: '@returns' command used in a comment that is attached to a function returning void [-Wdocumentation] llvm-svn: 368957
* [X86] Remove some dead code and combine some repeated code that's left.Craig Topper2019-08-151-17/+3
| | | | | | | | If the width is 256 bits, then we must have AVX so the else here was unnecessary. Once that's removed then the >= 256 bit code is identical to the 128 bit code with a different VT so combine them. llvm-svn: 368956
* [NFC] Update doc comment to fix warning.Jonas Devlieghere2019-08-151-2/+0
| | | | | | | This fixes the warning: parameter 'EnableNullFPSuppression' not found in the function declaration [-Wdocumentation] llvm-svn: 368954
* Revert "Expose TailCallKind via the LLVM C API"Jonas Devlieghere2019-08-154-61/+3
| | | | | | | This is failing on several build bots. Reverting as discussed in https://reviews.llvm.org/D66061. llvm-svn: 368953
* Revert "[compiler-rt] Migrate llvm::make_unique to std::make_unique"Jonas Devlieghere2019-08-151-13/+13
| | | | | | | | | | The X-ray unit tests in compiler-rt are overriding the C++ version by explicitly passing -std=c++11 in the compiler invocation. This poses a problem as these tests are including LLVM headers that can now use C++14 features. I'm temporarily reverting this as I investigate the correct solution. llvm-svn: 368952
* gn build: Merge r368918Vitaly Buka2019-08-151-0/+1
| | | | llvm-svn: 368951
* [NFCI] Always initialize BugReport const fieldsAlex Langford2019-08-151-2/+4
| | | | | | | | | | | | | | | | | Summary: Some compilers require that const fields of an object must be explicitly initialized by the constructor. I ran into this issue building with clang 3.8 on Ubuntu 16.04. Reviewers: compnerd, Szelethus, NoQ Subscribers: cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66265 llvm-svn: 368950
* [coroutine] Fixes "cannot move instruction since its users are not dominated ↵Gor Nishanov2019-08-154-148/+270
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | by CoroBegin" problem. Summary: Fixes https://bugs.llvm.org/show_bug.cgi?id=36578 and https://bugs.llvm.org/show_bug.cgi?id=36296. Supersedes: https://reviews.llvm.org/D55966 One of the fundamental transformation that CoroSplit pass performs before splitting the coroutine is to find which values need to survive between suspend and resume and provide a slot for them in the coroutine frame to spill and restore the value as needed. Coroutine frame becomes available once the storage for it was allocated and that point is marked in the pre-split coroutine with a llvm.coro.begin intrinsic. FE normally puts all of the user-authored code that would be accessing those values after llvm.coro.begin, however, sometimes instructions accessing those values would end up prior to coro.begin. For example, writing out a value of the parameter into the alloca done by the FE or instructions that are added by the optimization passes such as SROA when it rewrites allocas. Prior to this change, CoroSplit pass would try to move instructions that may end up accessing the values in the coroutine frame after CoroBegin. However it would run into problems (report_fatal_error) if some of the values would be used both in the allocation function (for example allocator is passed as a parameter to a coroutine) and in the use-authored body of the coroutine. To handle this case and to simplify the instruction moving logic, this change removes all of the instruction moving. Instead, we only change the uses of the spilled values that are dominated by coro.begin and leave other instructions intact. Before: ``` %var = alloca i32 %1 = getelementptr .. %var; ; will move this one after coro.begin %f = call i8* @llvm.coro.begin( ``` After: ``` %var = alloca i32 %1 = getelementptr .. %var; stays put %f = call i8* @llvm.coro.begin( ``` If we discover that there is a potential write into an alloca, prior to coro.begin we would copy its value from the alloca into the spill slot in the coroutine frame. Before: ``` %var = alloca i32 store .. %var ; will move this one after coro.begin %f = call i8* @llvm.coro.begin( ``` After: ``` %var = alloca i32 store .. %var ;stays put %f = call i8* @llvm.coro.begin( %tmp = load %var store %tmp, %spill.slot.for.var ``` Note: This change does not handle array allocas as that is something that C++ FE does not produce, but, it can be added in the future if need arises Reviewers: llvm-commits, modocache, ben-clayton, tks2103, rjmccall Reviewed By: modocache Subscribers: bartdesmet Differential Revision: https://reviews.llvm.org/D66230 llvm-svn: 368949
* [sanitizer_common] Replace forkpty with posix_spawn on DarwinJulian Lettner2019-08-157-93/+100
| | | | | | | | | | | | | | | | | | | | | | | | | On Darwin, we currently use forkpty to communicate with the "atos" symbolizer. There are several problems that fork[pty] has, e.g. that after fork, interceptors are still active and this sometimes causes crashes or hangs. This is especially problematic for TSan, which uses interceptors for OS-provided locks and mutexes, and even Libc functions use those. This patch replaces forkpty with posix_spawn on Darwin. Since posix_spawn doesn't fork (at least on Darwin), the interceptors are not a problem. Another benefit is that we'll handle post-fork failures (e.g. sandbox disallows "exec") gracefully now. Related revisions and previous attempts that were blocked by or had to be revered due to test failures: https://reviews.llvm.org/D48451 https://reviews.llvm.org/D40032 Reviewed By: kubamracek Differential Revision: https://reviews.llvm.org/D65253 llvm-svn: 368947
* [compiler-rt] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-13/+13
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368946
* Expose TailCallKind via the LLVM C APIRobert Widmann2019-08-144-3/+61
| | | | | | | | | | | | | | | | Summary: This exposes `CallInst`'s tail call kind via new `LLVMGetTailCallKind` and `LLVMSetTailCallKind` functions. The motivation for this is to be able to see `musttail` for languages that require mandatory tail calls for correctness. Today only the weaker `LLVMSetTail` is exposed and there is no way to set `GuaranteedTailCallOpt` via the C API. Reviewers: CodaFi, jyknight, deadalnix, rnk Reviewed By: CodaFi Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66061 llvm-svn: 368945
* [clang-tools-extra] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1499-344/+344
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368944
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-14259-831/+831
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* [www] Update DR status page to match latest version of CWG issues list.Richard Smith2019-08-141-32/+134
| | | | llvm-svn: 368941
* Fix handling of class member access into a vector type.Richard Smith2019-08-147-12/+55
| | | | | | | | | | | | | | | | | | | | | | When handling a member access into a non-class, non-ObjC-object type, we would perform a lookup into the surrounding scope as if for an unqualified lookup. If the member access was followed by a '<' and this lookup (or the typo-correction for it) found a template name, we'd treat the member access as naming that template. Now we treat such accesses as never naming a template if the type of the object expression is of vector type, so that vector component accesses are never misinterpreted as naming something else. This is not entirely correct, since it is in fact valid to name a template from the enclosing scope in this context, when invoking a pseudo-destructor for the vector type via an alias template, but that's very much a corner case, and this change leaves that case only as broken as the corresponding case for Objective-C types is. This incidentally adds support for dr2292, which permits a 'template' keyword at the start of a member access naming a pseudo-destructor. llvm-svn: 368940
* Remove LVALUE / RVALUE workaroundsJF Bastien2019-08-144-40/+11
| | | | | | | | | | | | Summary: LLVM_HAS_RVALUE_REFERENCE_THIS and LLVM_LVALUE_FUNCTION shouldn't be needed anymore because the minimum compiler versions support them. Subscribers: jkorous, dexonsmith, cfe-commits, llvm-commits, hans, thakis, chandlerc, rnk Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D66240 llvm-svn: 368939
* [Attributor] Try to fix "missing field 'RetInsts' initializer" warningJohannes Doerfert2019-08-141-1/+1
| | | | | | http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/35674/steps/build_Lld/logs/stdio llvm-svn: 368938
* Improve anonymous class heuristic in ClangASTContext::CreateRecordTypeShafik Yaghmour2019-08-145-14/+49
| | | | | | | | | Summary: Currently the heuristic used in ClangASTContext::CreateRecordType to identify an anonymous class is that there is that name is a nullptr or simply a null terminator. This heuristic is not accurate since it will also sweep up unnamed classes and lambdas. The improved heuristic relies on the requirement that an anonymous class must be contained within a class. Differential Revision: https://reviews.llvm.org/D66175 llvm-svn: 368937
* [LLD] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1419-37/+37
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368936
* [Polly] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-142-2/+2
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368935
* [Bugpoint redesign] Modified Functions pass to consider declarationsDiego Trevino Ferrer2019-08-142-26/+16
| | | | | | | | | | | | | | Summary: This modification was put in place so the `ReduceMetadata` pass doesn't have to consider debug functions Reviewers: dblaikie Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66257 llvm-svn: 368934
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1463-110/+110
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
OpenPOWER on IntegriCloud