summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* SemaTemplateDeduction - silence static analyzer getAs<> null dereference ↵Simon Pilgrim2019-10-211-7/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375443
* SemaExceptionSpec - silence static analyzer getAs<> null dereference ↵Simon Pilgrim2019-10-211-4/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375440
* Add -Wbitwise-conditional-parentheses to warn on mixing '|' and '&' with "?:"Richard Trieu2019-10-191-2/+11
| | | | | | | | | | | | | | | | | | | | Extend -Wparentheses to cover mixing bitwise-and and bitwise-or with the conditional operator. There's two main cases seen with this: unsigned bits1 = 0xf0 | cond ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : 0x10 | cond2 ? 0x5 : 0x2; // Intended order of evaluation: unsigned bits1 = 0xf0 | (cond ? 0x4 : 0x1); unsigned bits2 = (cond1 ? 0xf0 : 0x10) | (cond2 ? 0x5 : 0x2); // Actual order of evaluation: unsigned bits1 = (0xf0 | cond) ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : ((0x10 | cond2) ? 0x5 : 0x2); Differential Revision: https://reviews.llvm.org/D66043 llvm-svn: 375326
* New tautological warning for bitwise-or with non-zero constant always true.Richard Trieu2019-10-191-6/+18
| | | | | | | | | | | | | | | | | | Taking a value and the bitwise-or it with a non-zero constant will always result in a non-zero value. In a boolean context, this is always true. if (x | 0x4) {} // always true, intended '&' This patch creates a new warning group -Wtautological-bitwise-compare for this warning. It also moves in the existing tautological bitwise comparisons into this group. A few other changes were needed to the CFGBuilder so that all bool contexts would be checked. The warnings in -Wtautological-bitwise-compare will be off by default due to using the CFG. Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666 Differential Revision: https://reviews.llvm.org/D66046 llvm-svn: 375318
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-194-35/+50
| | | | | | | | | | This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-192-21/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-195-127/+426
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-192-0/+35
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. llvm-svn: 375305
* [OPENMP50]Add support for master taskloop simd.Alexey Bataev2019-10-182-1/+75
| | | | | | Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
* [ObjC] Diagnose implicit type coercion from ObjC 'Class' to objectJames Y Knight2019-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pointer types. For example, in Objective-C mode, the initialization of 'x' in: ``` @implementation MyType + (void)someClassMethod { MyType *x = self; } @end ``` is correctly diagnosed with an incompatible-pointer-types warning, but in Objective-C++ mode, it is not diagnosed at all -- even though incompatible pointer conversions generally become an error in C++. This patch fixes that oversight, allowing implicit conversions involving Class only to/from unqualified-id, and between qualified and unqualified Class, where the protocols are compatible. Note that this does change some behaviors in Objective-C, as well, as shown by the modified tests. Of particular note is that assignment from from 'Class<MyProtocol>' to 'id<MyProtocol>' now warns. (Despite appearances, those are not compatible types. 'Class<MyProtocol>' is not expected to have instance methods defined by 'MyProtocol', while 'id<MyProtocol>' is.) Differential Revision: https://reviews.llvm.org/D67983 llvm-svn: 375125
* SemaExprCXX - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-171-3/+3
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375101
* SemaDeclObjC - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-171-3/+3
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375097
* Revert Tag CFI-generated data structures with "#pragma clang section" ↵Dmitry Mikulin2019-10-171-19/+0
| | | | | | | | attributes. This reverts r375022 (git commit e2692b3bc0327606748b6d291b9009d2c845ced5) llvm-svn: 375069
* [Concepts] ConceptSpecializationExprs manglingSaar Raz2019-10-171-1/+1
| | | | | | | | | Implement mangling for CSEs to match regular template-ids. Reviewed as part of D41569 <https://reviews.llvm.org/D41569>. Re-commit fixing failing test. llvm-svn: 375063
* [OPENMP]Allow priority clause in combined task-based directives.Alexey Bataev2019-10-161-13/+10
| | | | | | | The expression of the priority clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 375026
* Tag CFI-generated data structures with "#pragma clang section" attributes.Dmitry Mikulin2019-10-161-0/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D68808 llvm-svn: 375022
* Revert 374967 "[Concepts] ConceptSpecializationExprs mangling"Nico Weber2019-10-161-1/+1
| | | | | | | | | | | | | | | This reverts commit 5e34ad109ced8dbdea9500ee28180315b2aeba3d. The mangling test fails on Windows: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15944 It also fails on ppc64le: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/21092 Also revert follow-up 374971 "Fix failing mangle-concept.cpp test." (it did not help on Win/ppc64le). llvm-svn: 374985
* [Concepts] ConceptSpecializationExprs manglingSaar Raz2019-10-161-1/+1
| | | | | | | Implement mangling for CSEs to match regular template-ids. Reviewed as part of D41569. llvm-svn: 374967
* [OPENMP]Allow final clause in combined task-based directives.Alexey Bataev2019-10-151-3/+20
| | | | | | | The condition of the final clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374942
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-153-61/+48
| | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. llvm-svn: 374938
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-152-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 llvm-svn: 374934
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-156-26/+257
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-156-257/+26
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-156-26/+257
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-143-119/+194
| | | | | | | | | | | | | | | | | | | | | | | Summary: We don't know what context to use until the classification result is consumed by the parser, which could happen in a different semantic context. So don't build the expression that results from name classification until we get to that point and can handle it properly. This covers everything except C++ implicit class member access, which is a little awkward to handle properly in the face of the protected member access check. But it at least fixes all the currently-filed instances of PR43080. Reviewers: efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68896 llvm-svn: 374826
* [OPNEMP]Allow num_tasks clause in combined task-based directives.Alexey Bataev2019-10-141-5/+14
| | | | | | | The expression of the num_tasks clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374819
* [OPNEMP]Allow grainsize clause in combined task-based directives.Alexey Bataev2019-10-141-8/+97
| | | | | | | The expression of the grainsize clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374810
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-142-1/+135
| | | | | | | | | Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
* [OPENMP]Fix codegen for private variably length vars in combinedAlexey Bataev2019-10-142-1/+23
| | | | | | | | | | | constructs. If OpenMP construct includes several capturing regions and the variable is declared as private, the length of the inner variable length array is not captured in outer captured regions, only in the innermost region. Patch fixes this bug. llvm-svn: 374787
* Suppress false-positive -Wdeprecated-volatile warning from ↵Richard Smith2019-10-111-1/+7
| | | | | | __is_*_assignable(volatile T&, U). llvm-svn: 374580
* Reland r374450 with Richard Smith's comments and test fixed.Erich Keane2019-10-111-0/+6
| | | | | | | | | | The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374562
* Fix assertion failure for a cv-qualified array as a non-type templateRichard Smith2019-10-111-4/+10
| | | | | | | | | | parameter type. We were both failing to decay the array type to a pointer and failing to remove the top-level cv-qualifications. Fix this by decaying array parameters even if the parameter type is dependent. llvm-svn: 374496
* Revert 374450 "Fix __builtin_assume_aligned with too large values."Nico Weber2019-10-101-10/+0
| | | | | | | | | | | | | The test fails on Windows, with error: 'warning' diagnostics expected but not seen: File builtin-assume-aligned.c Line 62: requested alignment must be 268435456 bytes or smaller; assumption ignored error: 'warning' diagnostics seen but not expected: File builtin-assume-aligned.c Line 62: requested alignment must be 8192 bytes or smaller; assumption ignored llvm-svn: 374456
* Fix __builtin_assume_aligned with too large values.Erich Keane2019-10-101-0/+10
| | | | | | | | | | | | | | Code to handle __builtin_assume_aligned was allowing larger values, but would convert this to unsigned along the way. This patch removes the EmitAssumeAligned overloads that take unsigned to do away with this problem. Additionally, it adds a warning that values greater than 1 <<29 are ignored by LLVM. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374450
* [OPENMP50]Support for 'master taskloop' directive.Alexey Bataev2019-10-102-1/+62
| | | | | | Added full support for master taskloop directive. llvm-svn: 374437
* [sema] Revise `getCurrentMangleNumberContext` interface. NFC.Michael Liao2019-10-103-26/+31
| | | | | | | - Prefer returning mulitple values using a tuple instead of additional pointers/references. llvm-svn: 374274
* Re-land [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-10/+2
| | | | | | | | | | | This reverts r374268 (git commit c34385d07c7d59447bf836b740f032235391d121) I think I reverted this by mistake, so I'm relanding it. While my bisect found this revision, I think the crashes I'm seeing locally must be environmental. Maybe the version of clang I'm using miscompiles tot clang. llvm-svn: 374269
* Revert [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-2/+10
| | | | | | | | This reverts r374200 (git commit fd18e94697c987d5f24e25aa4e27adaffff3cce4) Causes crashes just compiling `int main() {}` on my machine. llvm-svn: 374268
* [CUDA][HIP] Fix host/device check with -fopenmpYaxun Liu2019-10-093-127/+155
| | | | | | | | | | | | | | | | CUDA/HIP program may be compiled with -fopenmp. In this case, -fopenmp is only passed to host compilation to take advantages of multi-threads computation. CUDA/HIP and OpenMP both use Sema::DeviceCallGraph to store functions to be analyzed and remove them once they decide the function is sure to be emitted. CUDA/HIP and OpenMP have different functions to determine if a function is sure to be emitted. To check host/device correctly for CUDA/HIP when -fopenmp is enabled, there needs a unified logic to determine whether a function is to be emitted. The logic needs to be aware of both CUDA and OpenMP logic. Differential Revision: https://reviews.llvm.org/D67837 llvm-svn: 374263
* [mangle] Fix mangling where an extra mangle context is required.Michael Liao2019-10-091-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - [Itanium C++ ABI][1], for certain contexts like default parameter and etc., mangling numbering will be local to the particular argument in which it appears. - However, for these cases, the mangle numbering context is allocated per expression evaluation stack entry. That causes, for example, two lambdas defined/used understand the same default parameter are numbered as the same value and, in turn, one of them is not generated at all. - In this patch, an extra mangle numbering context map is maintained in the AST context to map taht extra declaration context to its numbering context. So that, 2 different lambdas defined/used in the same default parameter are numbered differently. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: rsmith, eli.friedman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68715 llvm-svn: 374200
* [Sema] Emit diagnostics for uncorrected delayed typos at the end of TUIlya Biryukov2019-10-091-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of asserting all typos are corrected in the sema destructor. The sema destructor is not run in the common case of running the compiler with the -disable-free cc1 flag (which is the default in the driver). Having this assertion led to crashes in libclang and clangd, which are not reproducible when running the compiler. Asserting at the end of the TU could be an option, but finding all missing typo correction cases is hard and having worse diagnostics instead of a failing assertion is a better trade-off. For more discussion on this, see: https://lists.llvm.org/pipermail/cfe-dev/2019-July/062872.html Reviewers: sammccall, rsmith Reviewed By: rsmith Subscribers: usaxena95, dgoldman, jkorous, vsapsai, rnk, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64799 llvm-svn: 374152
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-092-15/+76
| | | | | | | | | | | | whose value is not ignored. We don't warn on all the cases that are deprecated: specifically, we choose to not warn for now if there are parentheses around the assignment but its value is not actually used. This seems like a more defensible rule, particularly for cases like sizeof(v = a), where the parens are part of the operand rather than the sizeof syntax. llvm-svn: 374135
* [c++20] Implement most of P1152R4.Richard Smith2019-10-093-0/+50
| | | | | | | | | | | | | | Diagnose some now-deprecated uses of volatile types: * as function parameter types and return types * as the type of a structured binding declaration * as the type of the lvalue operand of an increment / decrement / compound assignment operator This does not implement a check for the deprecation of simple assignments whose results are used; that check requires somewhat more complexity and will be addressed separately. llvm-svn: 374133
* [OPENMP50]Multiple vendors in vendor context must be treated as logicalAlexey Bataev2019-10-082-5/+7
| | | | | | | | | | | | | and of vendors, not or. If several vendors are provided in the same vendor context trait, the context shall match only if all vendors are matching, not one of them. This is per OpenMP 5.0, 2.3.3 Matching and Scoring Context Selectors, all selectors in the construct, device, and implementation sets of the context selector appear in the corresponding trait set of the OpenMP context. llvm-svn: 374107
* [BPF] do compile-once run-everywhere relocation for bitfieldsYonghong Song2019-10-081-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bpf specific clang intrinsic is introduced: u32 __builtin_preserve_field_info(member_access, info_kind) Depending on info_kind, different information will be returned to the program. A relocation is also recorded for this builtin so that bpf loader can patch the instruction on the target host. This clang intrinsic is used to get certain information to facilitate struct/union member relocations. The offset relocation is extended by 4 bytes to include relocation kind. Currently supported relocation kinds are enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64, }; for __builtin_preserve_field_info. The old access offset relocation is covered by FIELD_BYTE_OFFSET = 0. An example: struct s { int a; int b1:9; int b2:4; }; enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64, }; void bpf_probe_read(void *, unsigned, const void *); int field_read(struct s *arg) { unsigned long long ull = 0; unsigned offset = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_OFFSET); unsigned size = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_SIZE); #ifdef USE_PROBE_READ bpf_probe_read(&ull, size, (const void *)arg + offset); unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ lshift = lshift + (size << 3) - 64; #endif #else switch(size) { case 1: ull = *(unsigned char *)((void *)arg + offset); break; case 2: ull = *(unsigned short *)((void *)arg + offset); break; case 4: ull = *(unsigned int *)((void *)arg + offset); break; case 8: ull = *(unsigned long long *)((void *)arg + offset); break; } unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #endif ull <<= lshift; if (__builtin_preserve_field_info(arg->b2, FIELD_SIGNEDNESS)) return (long long)ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64); return ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64); } There is a minor overhead for bpf_probe_read() on big endian. The code and relocation generated for field_read where bpf_probe_read() is used to access argument data on little endian mode: r3 = r1 r1 = 0 r1 = 4 <=== relocation (FIELD_BYTE_OFFSET) r3 += r1 r1 = r10 r1 += -8 r2 = 4 <=== relocation (FIELD_BYTE_SIZE) call bpf_probe_read r2 = 51 <=== relocation (FIELD_LSHIFT_U64) r1 = *(u64 *)(r10 - 8) r1 <<= r2 r2 = 60 <=== relocation (FIELD_RSHIFT_U64) r0 = r1 r0 >>= r2 r3 = 1 <=== relocation (FIELD_SIGNEDNESS) if r3 == 0 goto LBB0_2 r1 s>>= r2 r0 = r1 LBB0_2: exit Compare to the above code between relocations FIELD_LSHIFT_U64 and FIELD_LSHIFT_U64, the code with big endian mode has four more instructions. r1 = 41 <=== relocation (FIELD_LSHIFT_U64) r6 += r1 r6 += -64 r6 <<= 32 r6 >>= 32 r1 = *(u64 *)(r10 - 8) r1 <<= r6 r2 = 60 <=== relocation (FIELD_RSHIFT_U64) The code and relocation generated when using direct load. r2 = 0 r3 = 4 r4 = 4 if r4 s> 3 goto LBB0_3 if r4 == 1 goto LBB0_5 if r4 == 2 goto LBB0_6 goto LBB0_9 LBB0_6: # %sw.bb1 r1 += r3 r2 = *(u16 *)(r1 + 0) goto LBB0_9 LBB0_3: # %entry if r4 == 4 goto LBB0_7 if r4 == 8 goto LBB0_8 goto LBB0_9 LBB0_8: # %sw.bb9 r1 += r3 r2 = *(u64 *)(r1 + 0) goto LBB0_9 LBB0_5: # %sw.bb r1 += r3 r2 = *(u8 *)(r1 + 0) goto LBB0_9 LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0) LBB0_9: # %sw.epilog r1 = 51 r2 <<= r1 r1 = 60 r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2 LBB0_11: # %sw.epilog exit Considering verifier is able to do limited constant propogation following branches. The following is the code actually traversed. r2 = 0 r3 = 4 <=== relocation r4 = 4 <=== relocation if r4 s> 3 goto LBB0_3 LBB0_3: # %entry if r4 == 4 goto LBB0_7 LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0) LBB0_9: # %sw.epilog r1 = 51 <=== relocation r2 <<= r1 r1 = 60 <=== relocation r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2 LBB0_11: # %sw.epilog exit For native load case, the load size is calculated to be the same as the size of load width LLVM otherwise used to load the value which is then used to extract the bitfield value. Differential Revision: https://reviews.llvm.org/D67980 llvm-svn: 374099
* [OPENMP50]Allow functions in declare variant directive to have differentAlexey Bataev2019-10-082-4/+6
| | | | | | | | | | C linkage. After some discussion with OpenMP developers, it was decided that the functions with the different C linkage can be used in declare variant directive. llvm-svn: 374057
* [Diagnostics] Silence -Wsizeof-array-div for character buffersJames Clarke2019-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Character buffers are sometimes used to represent a pool of memory that contains non-character objects, due to them being synonymous with a stream of bytes on almost all modern architectures. Often, when interacting with hardware devices, byte buffers are therefore used as an intermediary and so we can end Character buffers are sometimes used to represent a pool of memory that contains non-character objects, due to them being synonymous with a stream of bytes on almost all modern architectures. Often, when interacting with hardware devices, byte buffers are therefore used as an intermediary and so we can end up generating lots of false-positives. Moreover, due to the ability of character pointers to alias non-character pointers, the strict aliasing violations that would generally be implied by the calculations caught by the warning (if the calculation itself is in fact correct) do not apply here, and so although the length calculation may be wrong, that is the only possible issue. Reviewers: rsmith, xbolva00, thakis Reviewed By: xbolva00, thakis Subscribers: thakis, lebedev.ri, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68526 llvm-svn: 374035
* [Diagnostics] Emit better -Wbool-operation's warning message if we known ↵David Bolvansky2019-10-072-4/+7
| | | | | | that the result is always true llvm-svn: 373973
* [OPENMP50]Treat range-based for as canonical loop.Alexey Bataev2019-10-072-11/+43
| | | | | | | According to OpenMP 5.0, range-based for is also considered as a canonical form of loops. llvm-svn: 373939
* Sema - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-074-11/+11
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 373911
OpenPOWER on IntegriCloud