summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [llvm-c] Make LLVMGetStringErrorTypeId a proper prototypeAnders Waldenborg2019-05-061-1/+1
| | | | | | | | | | | | In C a function declaration with an empty argument list isn't a real prototype, it will allow calling the function with any number of arguments. It will also cause warnings when used in C code compiled with '-Wstrict-prototypes' Reviewed By: whitequark Differential Revision: https://reviews.llvm.org/D61568 llvm-svn: 360012
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-0613-125/+105
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* Use DiagRuntimeBehavior for -Wunsequenced to weed out false positivesRichard Smith2019-05-067-23/+43
| | | | | | | | | where either the modification or the other access is unreachable. This reverts r359984 (which reverted r359962). The bug in clang-tidy's test suite exposed by the original commit was fixed in r360009. llvm-svn: 360010
* Fix test to avoid assuming clang will diagnose problems in unreachable code.Richard Smith2019-05-061-0/+2
| | | | llvm-svn: 360009
* [SelectionDAG] Replace llvm_unreachable at the end of getCopyFromParts with ↵Craig Topper2019-05-061-1/+1
| | | | | | | | | | | | | | | | a report_fatal_error. Based on PR41748, not all cases are handled in this function. llvm_unreachable is treated as an optimization hint than can prune code paths in a release build. This causes weird behavior when PR41748 is encountered on a release build. It appears to generate an fp_round instruction from the floating point code. Making this a report_fatal_error prevents incorrect optimization of the code and will instead generate a message to file a bug report. llvm-svn: 360008
* Fix up after r360006.Richard Smith2019-05-061-1/+1
| | | | llvm-svn: 360007
* [c++20] Implement P1009R2: allow omitting the array bound in an arrayRichard Smith2019-05-0619-80/+170
| | | | | | | | | | new expression. This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language modes (though it can never actually be used before C++11 mode). llvm-svn: 360006
* The 'CodeGenObjC/illegal-UTF8.m' get failed with Clang built with 32-bit ↵Galina Kistanova2019-05-061-1/+1
| | | | | | | | | | | | | | targets only (as example ARM-only) with the following error: error: unable to create target: 'No available targets are compatible with triple "< ... any 64-bit target triple ... >"' I didn't find any 64-bit dependencies for the test and I think removing '-m64' option should fix the problem and allow this test for any target specified by LLVM_DEFAULT_TARGET_TRIPLE. Patch by Vlad Vereschaka. Differential Revision: https://reviews.llvm.org/D61345 llvm-svn: 360005
* [libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not ↵Petr Hosek2019-05-062-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | defining them When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61572 llvm-svn: 360004
* [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining themPetr Hosek2019-05-062-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61571 llvm-svn: 360003
* [clang-tidy] openmp-exception-escape check: point to the structured-blockRoman Lebedev2019-05-052-8/+8
| | | | | | | | | | | | | I'm not sure what i was thinking when i wrote it to point at the directive. It's at the very least confusing, and in the `for` is very misleading. We should point at the actual Stmt out of which the exception escapes, to highlight where it should be fixed e.g. via adding try-catch block. Yes, this breaks existing NOLINT, which is why this change needs to happen now, not any later. llvm-svn: 360002
* [X86] Pull out repeated Subtarget feature tests. NFCI.Simon Pilgrim2019-05-051-12/+11
| | | | | | Avoids a scan-build "uninitialized value" warning in X86FastISel::X86SelectFPExtOrFPTrunc llvm-svn: 360001
* [TargetLowering] getValueType - use dyn_cast directly to find VectorType. NFCI.Simon Pilgrim2019-05-051-10/+9
| | | | | | | | Matches what we do in other getValueType functions and fixes a null dereference warning in scan-build. Also cleans up the rest of the function - use auto and standardize the variable names. llvm-svn: 360000
* [TTI][X86] Make getAddressComputationCost cost value const. NFCI.Simon Pilgrim2019-05-051-1/+1
| | | | llvm-svn: 359999
* [analyzer][UninitializedObjectChecker] PR41741: Regard all scalar types as ↵Kristof Umann2019-05-052-8/+36
| | | | | | | | | | | | | | | | | | | | primitive. https://bugs.llvm.org/show_bug.cgi?id=41741 Pretty much the same as D61246 and D61106, this time for __complex__ types. Upon further investigation, I realized that we should regard all types Type::isScalarType returns true for as primitive, so I merged isMemberPointerType(), isBlockPointerType() and isAnyComplexType()` into that instead. I also stumbled across yet another bug, https://bugs.llvm.org/show_bug.cgi?id=41753, but it seems to be unrelated to this checker. Differential Revision: https://reviews.llvm.org/D61569 llvm-svn: 359998
* [NFC] BasicBlock: generalize replaceSuccessorsPhiUsesWith(), take Old bbRoman Lebedev2019-05-052-7/+14
| | | | | | | | | | Thus it does not assume that the old basic block is the basic block for which we are looking at successors. Not reviewed, but seems rather trivial, in line with the rest of previous few patches. llvm-svn: 359997
* [NFC] BasicBlock: refactor changePhiUses() out of replacePhiUsesWith(), use itRoman Lebedev2019-05-055-37/+32
| | | | | | | | | | | | | | | | | | | | | Summary: It is a common thing to loop over every `PHINode` in some `BasicBlock` and change old `BasicBlock` incoming block to a new `BasicBlock` incoming block. `replaceSuccessorsPhiUsesWith()` already had code to do that, it just wasn't a function. So outline it into a new function, and use it. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61013 llvm-svn: 359996
* [NFC] PHINode: introduce replaceIncomingBlockWith() function, use itRoman Lebedev2019-05-055-38/+17
| | | | | | | | | | | | | | | | | | | | Summary: There is `PHINode::getBasicBlockIndex()`, `PHINode::setIncomingBlock()` and `PHINode::getNumOperands()`, but no function to replace every specified `BasicBlock*` predecessor with some other specified `BasicBlock*`. Clearly, there are a lot of places that could use that functionality. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61011 llvm-svn: 359995
* [NFC] Instruction: introduce replaceSuccessorWith() function, use itRoman Lebedev2019-05-053-3/+12
| | | | | | | | | | | | | | | | | | | | Summary: There is `Instruction::getNumSuccessors()`, `Instruction::getSuccessor()` and `Instruction::setSuccessor()`, but no function to replace every specified `BasicBlock*` successor with some other specified `BasicBlock*`. I've found one place where it should clearly be used. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61010 llvm-svn: 359994
* [NFC][Utils] deleteDeadLoop(): add an assert that exit block has some ↵Roman Lebedev2019-05-051-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | non-PHI instruction Summary: If `deleteDeadLoop()` is called on such a loop, that has "bad" exit block, one that e.g. has no terminator instruction, the `DIBuilder::insertDbgValueIntrinsic()` will be told to insert the Dbg Value Intrinsic after `nullptr` (since there is no first non-PHI instruction), which will cause it to not insert those instructions into any basic block. The instructions will be parent-less, and IR verifier will complain. It is rather obvious to track down the root cause when that happens, so let's just assert it never happens. Reviewers: sanjoy, davide, vsk Reviewed By: vsk Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61008 llvm-svn: 359993
* [test] Remove randomnessJonas Devlieghere2019-05-051-8/+3
| | | | | | | | This particular test fails once every so many runs on GreenDragon. Given that the randomness in the inferior isn't critical to the test, I removed it in the hopes that it is the cause of the flakiness. llvm-svn: 359992
* Move getOpcode() call into if statement. NFCI.Simon Pilgrim2019-05-051-2/+1
| | | | | | Avoids a cppcheck "Local variable name shadows outer variable" warning. llvm-svn: 359991
* Precommit an FNeg InstructionSimplify test.Cameron McInally2019-05-051-0/+11
| | | | llvm-svn: 359990
* [SLPVectorizer] Prefer pre-increments. NFCI.Simon Pilgrim2019-05-051-3/+3
| | | | llvm-svn: 359989
* [LLParser] Remove unused variable after r359987. NFCCraig Topper2019-05-051-1/+0
| | | | llvm-svn: 359988
* [LLParser] Remove unnecessary error check making sure NUW/NSW flags aren't ↵Craig Topper2019-05-051-6/+0
| | | | | | | | | | | | | | | | | | set on a non-integer operation. Summary: This check appears to be a leftover from when add/sub/mul could be either integer or fp. The NSW/NUW flags are only set for add/sub/mul/shl earlier. And we check that those operations only have integer types just below this. So it seems unnecessary to explicitly error for NUW/NSW being used on a add/sub/mul that have the wrong type that would later error for that. Reviewers: spatel, dblaikie, jyknight, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D61562 llvm-svn: 359987
* [LLParser] Simplify type checking in ParseArithmetic and ParseUnaryOp.Craig Topper2019-05-052-37/+18
| | | | | | | | | | | | | | | | | | | Summary: These methods previously took a 0, 1, or 2 to indicate what types were allowed, but the 0 encoding which meant both fp and integer types has been unused for years. Its leftover from when add/sub/mul used to be shared between int and fp Simplify it by changing it to just a bool to distinquish int and fp. Reviewers: spatel, dblaikie, jyknight, arsenm Reviewed By: spatel Subscribers: wdng, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61561 llvm-svn: 359986
* [Constants] Simplify type checking switch in ConstantExpr::get.Craig Topper2019-05-051-26/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: Remove duplicate checks that both operands have the same type. This is checked before the switch. Use 'integer' or 'floating-point' instead of 'arithmetic' type. I think this might be a leftover to the days when floating point and integer operations shared the same opcodes. Reviewers: spatel, RKSimon, dblaikie Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61558 llvm-svn: 359985
* Revert rL359962 : Use DiagRuntimeBehavior for -Wunsequenced to weed out ↵Simon Pilgrim2019-05-057-43/+23
| | | | | | | | | | false positives where either the modification or the other access is unreachable. ........ Try to fix buildbots llvm-svn: 359984
* [MCA] Notify event listeners when instructions transition to the Pending ↵Andrea Di Biagio2019-05-055-11/+48
| | | | | | state. NFCI llvm-svn: 359983
* Add FNeg IR constant folding supportCameron McInally2019-05-0511-61/+120
| | | | llvm-svn: 359982
* [X86] Make X86RegisterInfo(const Triple &TT) constructor explicit.Simon Pilgrim2019-05-051-1/+1
| | | | | | Fixes cppcheck warning. llvm-svn: 359981
* [clang] fixing -ast-print for variadic parameter pack in lambda captureNicolas Lesser2019-05-052-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: currently for: ``` template<typename ... T> void f(T... t) { auto l = [t...]{}; } ``` `clang -ast-print file.cpp` outputs: ``` template <typename ...T> void f(T ...t) { auto l = [t] { } ; } ``` notice that there is not `...` in the capture list of the lambda. this patch fixes this issue. and add test for it. Patch by Tyker Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61556 llvm-svn: 359980
* [C++] Interpret unknown identifier in parameter clause as unknown typeNicolas Lesser2019-05-053-4/+5
| | | | | | instead of as parameter name without a type. llvm-svn: 359979
* [lldb] [lit] Simplify general-purpose register testsMichal Gorny2019-05-054-61/+27
| | | | | | | | | Use output constraints for specific general-purpose registers in order to simplify the tests. They save us from having to manually put the values in correct registers, and reduce the number of registers needed as a result. llvm-svn: 359978
* [lldb] [lit] Fix more filename mismatches in Register testsMichal Gorny2019-05-052-2/+2
| | | | llvm-svn: 359977
* [X86] Fix some cppcheck "Local variable name shadows outer variable" ↵Simon Pilgrim2019-05-051-44/+42
| | | | | | warnings. NFCI. llvm-svn: 359976
* [SLPVectorizer] Make getSpillCost() const. NFCI.Simon Pilgrim2019-05-051-2/+9
| | | | | | Ideally getTreeCost() should be const as well but non-const Type creation would need to be addressed first. llvm-svn: 359975
* [SelectionDAG] Use any_of/all_of where possible. NFCI.Simon Pilgrim2019-05-051-14/+4
| | | | llvm-svn: 359974
* Move Value *RHSCIOp def into the scope where its actually used. NFCI.Simon Pilgrim2019-05-051-2/+1
| | | | llvm-svn: 359973
* Add InstCombine tests for FNeg instruction.Cameron McInally2019-05-041-0/+46
| | | | llvm-svn: 359970
* [CodeGenPrepare] limit overflow intrinsic matching to a single basic block ↵Sanjay Patel2019-05-044-49/+64
| | | | | | | | | | | | | | | | | | | | | (2nd try) This is a subset of the original commit from rL359879 which was reverted because it could crash when using the 'RemovedInstructions' structure that enables delayed deletion of dead instructions. The motivating compile-time win does not require that change though. We should get most of that win from this change alone. Using/updating a dominator tree to match math overflow patterns may be very expensive in compile-time (because of the way CGP uses a DT), so just handle the single-block case. See post-commit thread for rL354298 for more details: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190422/646276.html Differential Revision: https://reviews.llvm.org/D61075 llvm-svn: 359969
* [NFC] Add parentheses to avoid -Wparentheses.Nicolas Lesser2019-05-041-1/+1
| | | | llvm-svn: 359968
* [c++20] Implement P0428R2 - Familiar template syntax for generic lambdasHamza Sood2019-05-0429-61/+464
| | | | | | Differential Revision: https://reviews.llvm.org/D36527 llvm-svn: 359967
* [lldb] Fix buildbot failure due to clang AST change.Nicolas Lesser2019-05-041-2/+6
| | | | | | | In r359949 several AST node constructors were modified without the corresponding change in lldb, which caused build failures. llvm-svn: 359966
* [llvm-nm] Convert weak.test to use yaml2obj and fix unntested 'v'Fangrui Song2019-05-042-6/+35
| | | | | | This restores part of the good change reverted by r359830. llvm-svn: 359965
* [c++20] Implement tweaked __VA_OPT__ rules from P1042R1:Richard Smith2019-05-047-24/+116
| | | | | | | | | | * __VA_OPT__ is expanded if the *expanded* __VA_ARGS__ is non-empty, not if the original argument contained no tokens. * Placemarkers at the start and end of __VA_OPT__ are retained just long enough to paste them with adjacent ## operators. We never paste "across" a discarded placemarker. llvm-svn: 359964
* [AMDGPU] Fixed asan error after D61536Stanislav Mekhanoshin2019-05-041-1/+1
| | | | llvm-svn: 359963
* Use DiagRuntimeBehavior for -Wunsequenced to weed out false positivesRichard Smith2019-05-047-23/+43
| | | | | | where either the modification or the other access is unreachable. llvm-svn: 359962
* AMDGPU] gfx1010 hazard recognizerStanislav Mekhanoshin2019-05-047-3/+1172
| | | | | | Differential Revision: https://reviews.llvm.org/D61536 llvm-svn: 359961
OpenPOWER on IntegriCloud