summaryrefslogtreecommitdiffstats
path: root/clang
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-111-2/+1
| | | | Use castAs<> instead of getAs<> since the pointer is dereferenced immediately below and castAs will perform the null assertion for us.
* [Sema] Improve -Wrange-loop-analysis warnings.Mark de Wever2020-01-113-4/+109
| | | | | | | | | | | | | | | No longer generate a diagnostic when a small trivially copyable type is used without a reference. Before the test looked for a POD type and had no size restriction. Since the range-based for loop is only available in C++11 and POD types are trivially copyable in C++11 it's not required to test for a POD type. Since copying a large object will be expensive its size has been restricted. 64 bytes is a common size of a cache line and if the object is aligned the copy will be cheap. No performance impact testing has been done. Differential Revision: https://reviews.llvm.org/D72212
* Remove umask testsAlexandre Ganea2020-01-101-11/+0
| | | | | | | These tests were added in 18627115f4d2db5dc73207e0b5312f52536be7dd and e08b59f81d950bd5c8b8528fcb3ac4230c7b736c for validating a refactoring. Removing because they break on ACL-controlled folders on Ubuntu, and their added value is low. Differential Revision: https://reviews.llvm.org/D70854
* [Concepts] Fix MarkUsedTemplateParameters for exprsSaar Raz2020-01-111-25/+20
| | | | | | D41910 introduced a recursive visitor to MarkUsedTemplateParameters, but disregarded the 'Depth' parameter, and had incorrect assertions. This fixes the visitor and removes the assertions.
* [Driver] Fix OptionClass of -fconvergent-functions and -fms-volatile (Joined ↵Fangrui Song2020-01-101-2/+2
| | | | -> Flag)
* driver: Allow -fdebug-compilation-dir=foo in joined form.Nico Weber2020-01-107-4/+19
| | | | | | | All 130+ f_Group flags that take an argument allow it after a '=', except for fdebug-complation-dir. Add a Joined<> alias so that it behaves consistently with all the other f_Group flags. (Keep the old Separate flag for backwards compat.)
* Clean up and slightly generalize implementation of composite pointerRichard Smith2020-01-103-126/+245
| | | | | | | | | | | type computation, in preparation for P0388R4, which adds another few cases here. We now properly handle forming multi-level composite pointer types involving nested Objective-C pointer types (as is consistent with including them as part of the notion of 'similar types' on which this rule is based). We no longer lose non-CVR qualifiers on nested pointer types.
* Add a FIXME and corresponding test coverage for some suspicious behaviorRichard Smith2020-01-103-0/+33
| | | | forming composite ObjC pointer types in comparisons.
* Remove redundant implicit cast creation.Richard Smith2020-01-101-2/+0
| | | | | FindCompositePointerType has already cast the operands to the composite type for us in the case where it succeeds.
* Improve precision of documentation comment.Richard Smith2020-01-101-2/+2
|
* Only destroy static locals if they have non-trivial destructors.Richard Smith2020-01-102-1/+14
| | | | | | | This fixes a regression introduced in 2b4fa5348ee157b6b1a1af44d0137ca8c7a71573 that caused us to emit shutdown-time destruction for variables with ARC ownership, using C++-specific functions that don't exist in C implementations.
* Implement new AST matcher hasAnyCapture to match on LambdaExpr captures.Reid2020-01-104-0/+97
| | | | Accepts child matchers cxxThisExpr to match on capture of this and also on varDecl.
* [ASTMatchers] Make test more clear about what it is verifyingStephen Kelly2020-01-101-2/+5
|
* [Driver][PowerPC] Move powerpcspe logic from cc1 to DriverFangrui Song2020-01-104-4/+8
| | | | | | | | | Follow-up of D72014. It is more appropriate to use a target feature instead of a SubTypeArch to express the difference. Reviewed By: #powerpc, jhibbits Differential Revision: https://reviews.llvm.org/D72433
* [clang] Fix out-of-bounds memory access in ComputeLineNumbersJan Korous2020-01-102-13/+32
| | | | Differential Revision: https://reviews.llvm.org/D72409
* [analyzer] Move PlacementNewChecker to alphaGabor Marton2020-01-103-8/+8
|
* [Driver][CodeGen] Add -fpatchable-function-entry=N[,0]Fangrui Song2020-01-109-0/+58
| | | | | | | | | | | In the backend, this feature is implemented with the function attribute "patchable-function-entry". Both the attribute and XRay use TargetOpcode::PATCHABLE_FUNCTION_ENTER, so the two features are incompatible. Reviewed By: ostannard, MaskRay Differential Revision: https://reviews.llvm.org/D72222
* Support function attribute patchable_function_entryFangrui Song2020-01-108-1/+99
| | | | | | | | | This feature is generic. Make it applicable for AArch64 and X86 because the backend has only implemented NOP insertion for AArch64 and X86. Reviewed By: nickdesaulniers, aaron.ballman Differential Revision: https://reviews.llvm.org/D72221
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-101-1/+1
| | | | Use castAs<> instead of getAs<> since the pointer is dereferenced immediately below and castAs will perform the null assertion for us.
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-101-1/+1
| | | | Use castAs<> instead of getAs<> since the pointer is dereferenced immediately below and castAs will perform the null assertion for us.
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-101-1/+1
| | | | Use cast<> instead of dyn_cast<> since we know that the pointer should be valid (and is dereferenced immediately).
* [analyzer] Add PlacementNewCheckerGabor Marton2020-01-106-0/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This checker verifies if default placement new is provided with pointers to sufficient storage capacity. Noncompliant Code Example: #include <new> void f() { short s; long *lp = ::new (&s) long; } Based on SEI CERT rule MEM54-CPP https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM54-CPP.+Provide+placement+new+with+properly+aligned+pointe This patch does not implement checking of the alignment. Reviewers: NoQ, xazax.hun Subscribers: mgorny, whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat Tags: #clang Differential Revision: https://reviews.llvm.org/D71612
* Add support for __declspec(guard(nocf))Andrew Paverd2020-01-107-0/+226
| | | | | | | | | | | | | | | | | | Summary: Avoid using the `nocf_check` attribute with Control Flow Guard. Instead, use a new `"guard_nocf"` function attribute to indicate that checks should not be added on indirect calls within that function. Add support for `__declspec(guard(nocf))` following the same syntax as MSVC. Reviewers: rnk, dmajor, pcc, hans, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, tomrittervg, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72167
* [NFC] format unittest for ExprMutAnalyzerJonas Toth2020-01-101-29/+24
| | | | | | This formatting is a preparation for review in https://reviews.llvm.org/D54943 to separate pure formatting changes from actual testing changes.
* [FPEnv] Generate constrained FP comparisons from clangUlrich Weigand2020-01-103-11/+319
| | | | | | | | | | | | | | | | | | | | | Update the IRBuilder to generate constrained FP comparisons in CreateFCmp when IsFPConstrained is true, similar to the other places in the IRBuilder. Also, add a new CreateFCmpS to emit signaling FP comparisons, and use it in clang where comparisons are supposed to be signaling (currently, only when emitting code for the <, <=, >, >= operators). Note that there is currently no way to add fast-math flags to a constrained FP comparison, since this is implemented as an intrinsic call that returns a boolean type, and FMF are only allowed for calls returning a floating-point type. However, given the discussion around https://bugs.llvm.org/show_bug.cgi?id=42179, it seems that FCmp itself really shouldn't have any FMF either, so this is probably OK. Reviewed by: craig.topper Differential Revision: https://reviews.llvm.org/D71467
* [CodeComplete] Suggest 'return nullptr' in functions returning pointersIlya Biryukov2020-01-102-0/+31
| | | | | | | | | | Reviewers: kadircet Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72497
* [ARM,MVE] Make `vqrshrun` generate the right instruction.Simon Tatham2020-01-102-9/+9
| | | | | | | | | | | | | | | | | | Summary: A copy-paste error in `arm_mve.td` meant that the MVE `vqrshrun` intrinsic family was generating the `vqshrun` machine instruction, because in the IR intrinsic call, the rounding flag argument was set to 0 rather than 1. Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72496
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2020-01-101-2/+0
|
* [CMake] Support running libc++abi tests in CrossWinToARMLinux cache fileSergej Jaskiewicz2020-01-101-0/+3
| | | | | | | | | | | | | | | | | Summary: Now that D71894 has landed, we're able to run libc++abi tests remotely. For that we can use the same CMake command as before. The tests can be run using `ninja check-cxxabi`. Reviewers: andreil99, vvereschaka, aorlov Reviewed By: vvereschaka, aorlov Subscribers: mgorny, kristof.beyls, ldionne, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72459
* Allow system header to provide their own implementation of some builtinserge-sans-paille2020-01-106-1/+58
| | | | | | | | | | | | | | | | | | If a system header provides an (inline) implementation of some of their function, clang still matches on the function name and generate the appropriate llvm builtin, e.g. memcpy. This behavior is in line with glibc recommendation « users may not provide their own version of symbols » but doesn't account for the fact that glibc itself can provide inline version of some functions. It is the case for the memcpy function when -D_FORTIFY_SOURCE=1 is on. In that case an inline version of memcpy calls __memcpy_chk, a function that performs extra runtime checks. Clang currently ignores the inline version and thus provides no runtime check. This code fixes the issue by detecting functions whose name is a builtin name but also have an inline implementation. Differential Revision: https://reviews.llvm.org/D71082
* [Syntax] Update comment, remove stale FIXME. NFCIlya Biryukov2020-01-101-3/+3
|
* [ThinLTO] Pass CodeGenOpts like UnrollLoops/VectorizeLoop/VectorizeSLPWei Mi2020-01-092-0/+56
| | | | | | | | | | | | | down to pass builder in ltobackend. Currently CodeGenOpts like UnrollLoops/VectorizeLoop/VectorizeSLP in clang are not passed down to pass builder in ltobackend when new pass manager is used. This is inconsistent with the behavior when new pass manager is used and thinlto is not used. Such inconsistency causes slp vectorization pass not being enabled in ltobackend for O3 + thinlto right now. This patch fixes that. Differential Revision: https://reviews.llvm.org/D72386
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2020-01-0912-154/+280
| | | | | | | | | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-0921-172/+204
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* Add builtins for aligning and checking alignment of pointers and integersAlex Richardson2020-01-0913-11/+1025
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces three new builtins (which work on both pointers and integers) that can be used instead of common bitwise arithmetic: __builtin_align_up(x, alignment), __builtin_align_down(x, alignment) and __builtin_is_aligned(x, alignment). I originally added these builtins to the CHERI fork of LLVM a few years ago to handle the slightly different C semantics that we use for CHERI [1]. Until recently these builtins (or sequences of other builtins) were required to generate correct code. I have since made changes to the default C semantics so that they are no longer strictly necessary (but using them does generate slightly more efficient code). However, based on our experience using them in various projects over the past few years, I believe that adding these builtins to clang would be useful. These builtins have the following benefit over bit-manipulation and casts via uintptr_t: - The named builtins clearly convey the semantics of the operation. While checking alignment using __builtin_is_aligned(x, 16) versus ((x & 15) == 0) is probably not a huge win in readably, I personally find __builtin_align_up(x, N) a lot easier to read than (x+(N-1))&~(N-1). - They preserve the type of the argument (including const qualifiers). When using casts via uintptr_t, it is easy to cast to the wrong type or strip qualifiers such as const. - If the alignment argument is a constant value, clang can check that it is a power-of-two and within the range of the type. Since the semantics of these builtins is well defined compared to arbitrary bit-manipulation, it is possible to add a UBSAN checker that the run-time value is a valid power-of-two. I intend to add this as a follow-up to this change. - The builtins avoids int-to-pointer casts both in C and LLVM IR. In the future (i.e. once most optimizations handle it), we could use the new llvm.ptrmask intrinsic to avoid the ptrtoint instruction that would normally be generated. - They can be used to round up/down to the next aligned value for both integers and pointers without requiring two separate macros. - In many projects the alignment operations are already wrapped in macros (e.g. roundup2 and rounddown2 in FreeBSD), so by replacing the macro implementation with a builtin call, we get improved diagnostics for many call-sites while only having to change a few lines. - Finally, the builtins also emit assume_aligned metadata when used on pointers. This can improve code generation compared to the uintptr_t casts. [1] In our CHERI compiler we have compilation mode where all pointers are implemented as capabilities (essentially unforgeable 128-bit fat pointers). In our original model, casts from uintptr_t (which is a 128-bit capability) to an integer value returned the "offset" of the capability (i.e. the difference between the virtual address and the base of the allocation). This causes problems for cases such as checking the alignment: for example, the expression `if ((uintptr_t)ptr & 63) == 0` is generally used to check if the pointer is aligned to a multiple of 64 bytes. The problem with offsets is that any pointer to the beginning of an allocation will have an offset of zero, so this check always succeeds in that case (even if the address is not correctly aligned). The same issues also exist when aligning up or down. Using the alignment builtins ensures that the address is used instead of the offset. While I have since changed the default C semantics to return the address instead of the offset when casting, this offset compilation mode can still be used by passing a command-line flag. Reviewers: rsmith, aaron.ballman, theraven, fhahn, lebedev.ri, nlopes, aqjune Reviewed By: aaron.ballman, lebedev.ri Differential Revision: https://reviews.llvm.org/D71499
* [clang] Enforce triple in mempcpy testserge-sans-paille2020-01-091-1/+1
| | | | Fixes http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/2597
* [ms] [X86] Use "P" modifier on all branch-target operands in inline X86 ↵Eric Astor2020-01-091-0/+14
| | | | | | | | | | | | | | | | | | | assembly. Summary: Extend D71677 to apply to all branch-target operands, rather than special-casing call instructions. Also add a regression test for llvm.org/PR44272, since this finishes fixing it. Reviewers: thakis, rnk Reviewed By: thakis Subscribers: merge_guards_bot, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72417
* [Clang] Handle target-specific builtins returning aggregates.Simon Tatham2020-01-092-3/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A few of the ARM MVE builtins directly return a structure type. This causes an assertion failure at code-gen time if you try to assign the result of the builtin to a variable, because the `RValue` created in `EmitBuiltinExpr` from the `llvm::Value` produced by codegen is always made by `RValue::get()`, which creates a non-aggregate `RValue` that will fail an assertion when `AggExprEmitter::withReturnValueSlot` calls `Src.getAggregatePointer()`. A similar failure occurs if you try to use the struct return value directly to extract one field, e.g. `vld2q(address).val[0]`. The existing code-gen tests for those MVE builtins pass the returned structure type directly to the C `return` statement, which apparently managed to avoid that particular code path, so we didn't notice the crash. Now `EmitBuiltinExpr` checks the evaluation kind of the builtin's return value, and does the necessary handling for aggregate returns. I've added two extra test cases, both of which crashed before this change. Reviewers: dmgreen, rjmccall Reviewed By: rjmccall Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72271
* [OpenCL][Docs] Rename C++ for OpenCL labelSven van Haastregt2020-01-091-2/+3
| | | | To avoid potential confusion with OpenCL C++.
* Improve support of GNU mempcpyserge-sans-paille2020-01-096-4/+39
| | | | | | | - Lower to the memcpy intrinsic - Raise warnings when size/bounds are known Differential Revision: https://reviews.llvm.org/D71374
* [ARM,MVE] Fix valid immediate range for vsliq_n.Simon Tatham2020-01-092-1/+94
| | | | | | | | | | | In common with most MVE immediate shift instructions, the left shift takes an immediate in the range [0,n-1], while the right shift takes one in the range [1,n]. I had absent-mindedly made them both the latter. While I'm here, I've added a set of regression tests checking both ends of the immediate range for a representative sample of the immediate shifts.
* [OPENMP]Remove unused code, NFC.Alexey Bataev2020-01-092-102/+2
|
* [Concepts] Fix failing test on WindowsSaar Raz2020-01-091-3/+2
| | | | Fix test failed by D43357 on Windows.
* [ARM][MVE] MVE-I should not be disabled by -mfpu=noneMomchil Velikov2020-01-093-51/+74
| | | | | | | | | | | | | | | Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
* [Concepts] Function trailing requires clausesSaar Raz2020-01-0961-469/+2109
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-091-4/+3
| | | | Use cast<> instead of dyn_cast<> since we know that the pointer should be valid (and is dereferenced immediately below).
* Fix "pointer is null" static analyzer warnings. NFCI.Simon Pilgrim2020-01-091-2/+2
| | | | Use castAs<> instead of getAs<> since the pointer is dereferenced immediately below and castAs will perform the null assertion for us.
* Fix "pointer is null" static analyzer warnings. NFCI.Simon Pilgrim2020-01-091-0/+2
| | | | Assert that the pointers are non-null before dereferencing them.
* Fix MSVC unhandled enum warning. NFCI.Simon Pilgrim2020-01-091-0/+1
|
* [APFloat] Fix checked error assert failuresEhud Katz2020-01-091-5/+3
| | | | | | | | | | | `APFLoat::convertFromString` returns `Expected` result, which must be "checked" if the LLVM_ENABLE_ABI_BREAKING_CHECKS preprocessor flag is set. To mark an `Expected` result as "checked" we must consume the `Error` within. In many cases, we are only interested in knowing if an error occured, without the need to examine the error info. This is achieved, easily, with the `errorToBool()` API.
OpenPOWER on IntegriCloud