summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaChecking.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add builtins for aligning and checking alignment of pointers and integersAlex Richardson2020-01-091-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve support of GNU mempcpyserge-sans-paille2020-01-091-2/+5
| | | | | | | - Lower to the memcpy intrinsic - Raise warnings when size/bounds are known Differential Revision: https://reviews.llvm.org/D71374
* [OpenCL] Fix inconsistency between opencl and c11 atomic fetch max/minYaxun (Sam) Liu2019-12-271-2/+2
| | | | | | | | | | | | There is some inconsistency between opencl and c11 atomic fetch max/min after https://reviews.llvm.org/D46386 https://reviews.llvm.org/D55562 It is not reasonable to have such inconsistencies. This patch fixes that. Differential Revision: https://reviews.llvm.org/D71725
* [Sema] SequenceChecker: C++17 sequencing rules for built-in operators <<, ↵Bruno Ricci2019-12-221-25/+83
| | | | | | | | | | | >>, .*, ->*, =, op= Implement the C++17 sequencing rules for the built-in operators <<, >>, .*, ->*, = and op=. Differential Revision: https://reviews.llvm.org/D58297 Reviewed By: rsmith
* [Sema] SequenceChecker: Fix handling of operator ||, && and ?:Bruno Ricci2019-12-221-31/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | The current handling of the operators ||, && and ?: has a number of false positive and false negative. The issues for operator || and && are: 1. We need to add sequencing regions for the LHS and RHS as is done for the comma operator. Not doing so causes false positives in expressions like `((a++, false) || (a++, false))` (from PR39779, see PR22197 for another example). 2. In the current implementation when the evaluation of the LHS fails, the RHS is added to a worklist to be processed later. This results in false negatives in expressions like `(a && a++) + a`. Fix these issues by introducing sequencing regions for the LHS and RHS, and by not deferring the visitation of the RHS. The issues with the ternary operator ?: are similar, with the added twist that we should not warn on expressions like `(x ? y += 1 : y += 2)` since exactly one of the 2nd and 3rd expression is going to be evaluated, but we should still warn on expressions like `(x ? y += 1 : y += 2) = y`. Differential Revision: https://reviews.llvm.org/D57747 Reviewed By: rsmith
* [Sema] SequenceChecker: Add some comments + related small NFCsBruno Ricci2019-12-221-73/+122
| | | | | | | | | | | | NFCs factored out of the following patches: - Change all of the `Expr *` to `const Expr *` in SequenceChecker for const-correctness. SequenceChecker should not modify AST nodes. - Add some comments. - clang-format Differential Revision: https://reviews.llvm.org/D57659 Reviewed By: xbolva00
* Reland [NFC-I] Remove hack for fp-classification builtinsErich Keane2019-12-171-34/+24
| | | | | | | | | | | | | | | | | | The FP-classification builtins (__builtin_isfinite, etc) use variadic packs in the definition file to mean an overload set. Because of that, floats were converted to doubles, which is incorrect. There WAS a patch to remove the cast after the fact. THis patch switches these builtins to just be custom type checking, calls the implicit conversions for the integer members, and makes sure the correct L->R casts are put into place, then does type checking like normal. A future direction (that wouldn't be NFC) would consider making conversions for the floating point parameter legal. Note: The initial patch for this missed that certain systems need to still convert half to float, since they dont' support that type.
* [c++20] Add deprecation warnings for the expression forms deprecated by P1120R0.Richard Smith2019-12-161-29/+2
| | | | | | | | | | | | | | | | | | | This covers: * usual arithmetic conversions (comparisons, arithmetic, conditionals) between different enumeration types * usual arithmetic conversions between enums and floating-point types * comparisons between two operands of array type The deprecation warnings are on-by-default (in C++20 compilations); it seems likely that these forms will become ill-formed in C++23, so warning on them now by default seems wise. For the first two bullets, off-by-default warnings were also added for all the cases where we didn't already have warnings (covering language modes prior to C++20). These warnings are in subgroups of the existing -Wenum-conversion (except that the first case is not warned on if either enumeration type is anonymous, consistent with our existing -Wenum-conversion warnings).
* Revert "[NFC-I] Remove hack for fp-classification builtins"Erich Keane2019-12-161-18/+34
| | | | | | | | | | | This reverts commit b1e542f302c1ed796ad9f703d4d36e010afcb914. The original 'hack' didn't chop out fp-16 to double conversions, so systems that use FP16ConversionIntrinsics end up in IR-CodeGen with an i16 type isntead of a float type (like PPC64-BE). The bots noticed this. Reverting until I figure out how to fix this
* [NFC-I] Remove hack for fp-classification builtinsErich Keane2019-12-161-34/+18
| | | | | | | | | | | | | | | The FP-classification builtins (__builtin_isfinite, etc) use variadic packs in the definition file to mean an overload set. Because of that, floats were converted to doubles, which is incorrect. There WAS a patch to remove the cast after the fact. THis patch switches these builtins to just be custom type checking, calls the implicit conversions for the integer members, and makes sure the correct L->R casts are put into place, then does type checking like normal. A future direction (that wouldn't be NFC) would consider making conversions for the floating point parameter legal.
* Only Remove implicit conversion for the target that support fp16Jim Lin2019-12-101-1/+2
| | | | | | Remove implicit conversion that promotes half to double for the target that support fp16. If the target doesn't support fp16, fp16 will be converted to fp16 intrinsic.
* Remove implicit conversion that promotes half to other larger precision ↵Jim Lin2019-12-101-1/+15
| | | | | | | | | | | | | | | | | | | | types for fp classification builtins Summary: It shouldn't promote half to double or any larger precision types for fp classification builtins. Because fp classification builtins would get incorrect result with promoted argument. For example, __builtin_isnormal with a subnormal half value should return false, but it is not. That the subnormal half value is promoted to a normal double value. Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71049
* Reapply "Fix crash on switch conditions of non-integer types in templates"Elizabeth Andrews2019-12-031-0/+2
| | | | | | | | | | | | | | | | | | | | This patch reapplies commit 759948467ea. Patch was reverted due to a clang-tidy test fail on Windows. The test has been modified. There are no additional code changes. Patch was tested with ninja check-all on Windows and Linux. Summary of code changes: Clang currently crashes for switch statements inside a template when the condition is a non-integer field member because contextual implicit conversion is skipped when parsing the condition. This conversion is however later checked in an assert when the case statement is handled. The conversion is skipped when parsing the condition because the field member is set as type-dependent based on its containing class. This patch sets the type dependency based on the field's type instead. This patch fixes Bug 40982.
* [CIndex] Fix annotate-deep-statements test when using a Debug buildAlexandre Ganea2019-11-291-1/+2
| | | | Differential Revision: https://reviews.llvm.org/D70149
* [mips] Check that features required by built-ins are enabledSimon Atanasyan2019-11-291-2/+31
| | | | | | | | | | | | Now Clang does not check that features required by built-in functions are enabled. That causes errors in the backend reported in PR44018. This patch fixes this bug by checking that required features are enabled. This should fix PR44018. Differential Revision: https://reviews.llvm.org/D70808
* Atomics: support min/max orthogonallyTim Northover2019-11-211-17/+8
| | | | | | | | | | | | We seem to have been gradually growing support for atomic min/max operations (exposing longstanding IR atomicrmw instructions). But until now there have been gaps in the expected intrinsics. This adds support for the C11-style intrinsics (i.e. taking _Atomic, rather than individually blessed by C11 standard), and the variants that return the new value instead of the original one. That way, people won't be misled by trying one form and it not working, and the front-end is more friendly to people using _Atomic types, as we recommend.
* [Sema] Add a 'Semantic' parameter to Expr::isKnownToHaveBooleanValueErik Pilkington2019-11-201-1/+1
| | | | | | | | | Some clients of this function want to know about any expression that is known to produce a 0/1 value, and others care about expressions that are semantically boolean. This fixes a -Wswitch-bool regression I introduced in 8bfb353bb33c, pointed out by Chris Hamilton!
* [NFC] Refactor representation of materialized temporariesTyker2019-11-191-1/+1
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber2019-11-171-1/+1
| | | | | | This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
* [NFC] Refactor representation of materialized temporariesTyker2019-11-161-1/+1
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* AArch64: add arm64_32 support to Clang.Tim Northover2019-11-121-1/+4
|
* Revert "Reapply "Fix crash on switch conditions of non-integer types in ↵Melanie Blower2019-11-081-2/+0
| | | | | | | templates"" This reverts commit 759948467ea3181615d44d80f74ffeb260180fd0. There were build bot failures in clang-tidy
* Reapply "Fix crash on switch conditions of non-integer types in templates"Melanie Blower2019-11-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reapplies commit 76945821b9cad3. The first version broke buildbots due to clang-tidy test fails. The fails are because some errors in templates are now diagnosed earlier (does not wait till instantiation). I have modified the tests to add checks for these diagnostics/prevent these diagnostics. There are no additional code changes. Summary of code changes: Clang currently crashes for switch statements inside a template when the condition is a non-integer field member because contextual implicit conversion is skipped when parsing the condition. This conversion is however later checked in an assert when the case statement is handled. The conversion is skipped when parsing the condition because the field member is set as type-dependent based on its containing class. This patch sets the type dependency based on the field's type instead. This patch fixes Bug 40982. Reviewers: rnk, gribozavr2 Patch by: Elizabeth Andrews (eandrews) Differential revision: https://reviews.llvm.org/D69950
* [clang,ARM] Initial ACLE intrinsics for MVE.Simon Tatham2019-10-241-0/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit sets up the infrastructure for auto-generating <arm_mve.h> and doing clang-side code generation for the builtins it relies on, and demonstrates that it works by implementing a representative sample of the ACLE intrinsics, more or less matching the ones introduced in LLVM IR by D67158,D68699,D68700. Like NEON, that header file will provide a set of vector types like uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON, the ACLE spec for <arm_mve.h> includes a polymorphism system, so that you can write plain vaddq() and disambiguate by the vector types you pass to it. Unlike the corresponding NEON code, I've arranged to make every user- facing ACLE intrinsic into a clang builtin, and implement all the code generation inside clang. So <arm_mve.h> itself contains nothing but typedefs and function declarations, with the latter all using the new `__attribute__((__clang_builtin))` system to arrange that the user- facing function names correspond to the right internal BuiltinIDs. So the new MveEmitter tablegen system specifies the full sequence of IRBuilder operations that each user-facing ACLE intrinsic should translate into. Where possible, the ACLE intrinsics map to standard IR operations such as vector-typed `add` and `fadd`; where no standard representation exists, I call down to the sample IR intrinsics introduced in an earlier commit. Doing it like this means that you get the polymorphism for free just by using __attribute__((overloadable)): the clang overload resolution decides which function declaration is the relevant one, and _then_ its BuiltinID is looked up, so by the time we're doing code generation, that's all been resolved by the standard system. It also means that you get really nice error messages if the user passes the wrong combination of types: clang will show the declarations from the header file and explain why each one doesn't match. (The obvious alternative approach would be to have wrapper functions in <arm_mve.h> which pass their arguments to the underlying builtins. But that doesn't work in the case where one of the arguments has to be a constant integer: the wrapper function can't pass the constantness through. So you'd have to do that case using a macro instead, and then use C11 `_Generic` to handle the polymorphism. Then you have to add horrible workarounds because `_Generic` requires even the untaken branches to type-check successfully, and //then// if the user gets the types wrong, the error message is totally unreadable!) Reviewers: dmgreen, miyuki, ostannard Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67161
* 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
* 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
* [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
* [Diagnostics] Emit better -Wbool-operation's warning message if we known ↵David Bolvansky2019-10-071-0/+7
| | | | | | that the result is always true llvm-svn: 373973
* Sema - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-071-7/+7
| | | | | | 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
* [clang] fix a typo from r372531Yuanfang Chen2019-10-041-1/+1
| | | | | | | | | | | | Reviewers: xbolva00 Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68482 llvm-svn: 373792
* [Sema] Split out -Wformat-type-confusion from -Wformat-pedanticErik Pilkington2019-10-041-15/+33
| | | | | | | | | The warnings now in -Wformat-type-confusion don't align with how we interpret 'pedantic' in clang, and don't belong in -pedantic. Differential revision: https://reviews.llvm.org/D67775 llvm-svn: 373774
* Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim2019-10-031-1/+1
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us. llvm-svn: 373584
* Silence static analyzer getAs<VectorType> null dereference warnings. NFCI.Simon Pilgrim2019-10-021-5/+5
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<VectorType> directly and if not assert will fire for us. llvm-svn: 373478
* [Diagnostics] Warn if enumeration type mismatch in conditional expressionDavid Bolvansky2019-09-301-0/+28
| | | | | | | | | | | | | | | | | | Summary: - Useful warning - GCC compatibility (GCC warns in C++ mode) Reviewers: rsmith, aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67919 llvm-svn: 373252
* [NFC] Strenghten preconditions for warningDavid Bolvansky2019-09-241-1/+2
| | | | llvm-svn: 372775
* [Diagnostics] Handle tautological left shifts in boolean context David Bolvansky2019-09-241-5/+14
| | | | llvm-svn: 372749
* [Diagnostics] Do not diagnose unsigned shifts in boolean context ↵David Bolvansky2019-09-241-26/+21
| | | | | | | | (-Wint-in-bool-context) I was looking at old GCC's patch. Current "trunk" version avoids warning for unsigned case, GCC warns only for signed shifts. llvm-svn: 372708
* [Sema] Fix the atomic expr rebuilding order.Michael Liao2019-09-231-25/+65
| | | | | | | | | | | | | | | | Summary: - Rearrange the atomic expr order to the API order when rebuilding atomic expr during template instantiation. Reviewers: erichkeane Subscribers: jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67924 llvm-svn: 372640
* [Diagnostics] Warn if '<<' in bool context with -Wint-in-bool-context (GCC ↵David Bolvansky2019-09-231-1/+10
| | | | | | | | compatibility) Extracted from D63082, addressed review comments related to a warning message. llvm-svn: 372612
* [Diagnostics] Warn if ?: with integer constants always evaluates to trueDavid Bolvansky2019-09-221-0/+41
| | | | | | Extracted from D63082. GCC has this warning under -Wint-in-bool-context, but as noted in the D63082's review, we should put it under TautologicalConstantCompare. llvm-svn: 372531
* [CLANG][BPF] permit any argument type for __builtin_preserve_access_index()Yonghong Song2019-09-221-11/+1
| | | | | | | | | | | | | | | | | | | | Commit c15aa241f821 ("[CLANG][BPF] change __builtin_preserve_access_index() signature") changed the builtin function signature to PointerT __builtin_preserve_access_index(PointerT ptr) with a pointer type as the argument/return type, where argument and return types must be the same. There is really no reason for this constraint. The builtin just presented a code region so that IR builtins __builtin_{array, struct, union}_preserve_access_index can be applied. This patch removed the pointer type restriction to permit any argument type as long as it is permitted by the compiler. Differential Revision: https://reviews.llvm.org/D67883 llvm-svn: 372516
* Ensure AtomicExpr goes through SEMA checking after TreeTransformErich Keane2019-09-201-47/+54
| | | | | | | | | | | RebuildAtomicExpr was skipping doing semantic analysis which broke in the cases where the expressions were not dependent. This resulted in the ImplicitCastExpr from an array to a pointer being lost, causing a crash in IR CodeGen. Differential Revision: https://reviews.llvm.org/D67854 llvm-svn: 372422
* [CLANG][BPF] change __builtin_preserve_access_index() signatureYonghong Song2019-09-191-1/+11
| | | | | | | | | | | | | | | | | | | | | | | The clang intrinsic __builtin_preserve_access_index() currently has signature: const void * __builtin_preserve_access_index(const void * ptr) This may cause compiler warning when: - parameter type is "volatile void *" or "const volatile void *", or - the assign-to type of the intrinsic does not have "const" qualifier. Further, this signature does not allow dereference of the builtin result pointer as it is a "const void *" type, which adds extra step for the user to do type casting. Let us change the signature to: PointerT __builtin_preserve_access_index(PointerT ptr) such that the result and argument types are the same. With this, directly dereferencing the builtin return value becomes possible. Differential Revision: https://reviews.llvm.org/D67734 llvm-svn: 372294
* [Sema] Suppress -Wformat diagnostics for bool types when printed using %hhdErik Pilkington2019-09-181-0/+16
| | | | | | | | | | | Also, add a diagnostic under -Wformat for printing a boolean value as a character. rdar://54579473 Differential revision: https://reviews.llvm.org/D66856 llvm-svn: 372247
* [Sema] Split of versions of -Wimplicit-{float,int}-conversion for ↵Erik Pilkington2019-09-171-28/+59
| | | | | | | | | | | | | Objective-C BOOL Also, add a diagnostic group, -Wobjc-signed-char-bool, to control all these related diagnostics. rdar://51954400 Differential revision: https://reviews.llvm.org/D67559 llvm-svn: 372183
* [X86] Allow _MM_FROUND_CUR_DIRECTION and _MM_FROUND_NO_EXC to be used ↵Craig Topper2019-09-091-1/+3
| | | | | | | | | | together on instructions that only support SAE and not embedded rounding. Current for SAE instructions we only allow _MM_FROUND_CUR_DIRECTION(bit 2) or _MM_FROUND_NO_EXC(bit 3) to be used as the immediate passed to the inrinsics. But these instructions don't perform rounding so _MM_FROUND_CUR_DIRECTION is just sort of a default placeholder when you don't want to suppress exceptions. Using _MM_FROUND_NO_EXC by itself is really bit equivalent to (_MM_FROUND_NO_EXC | _MM_FROUND_TO_NEAREST_INT) since _MM_FROUND_TO_NEAREST_INT is 0. Since we aren't rounding on these instructions we should also accept (_MM_FROUND_CUR_DIRECTION | _MM_FROUND_NO_EXC) as equivalent to (_MM_FROUND_NO_EXC). icc allows this, but gcc does not. Differential Revision: https://reviews.llvm.org/D67289 llvm-svn: 371430
* [Diagnostics] Refactor code for -Wsizeof-pointer-div, catch more cases; also ↵David Bolvansky2019-09-061-1/+1
| | | | | | | | | | | | | | | | add -Wsizeof-array-div Previously, -Wsizeof-pointer-div failed to catch: const int *r; sizeof(r) / sizeof(int); Now fixed. Also introduced -Wsizeof-array-div which catches bugs like: sizeof(r) / sizeof(short); (Array element type does not match type of sizeof operand). llvm-svn: 371222
* [PowerPC][Altivec][Clang] Check compile-time constant for vec_dst*Jinsong Ji2019-09-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is follow up of https://reviews.llvm.org/D66699. We might get ISEL ICE if we call vec_dss with non const 3rd arg. ``` Cannot select: intrinsic %llvm.ppc.altivec.dst ``` We should check the constraints in clang and generate better error messages. Reviewers: nemanjai, hfinkel, echristo, #powerpc, wuzish Reviewed By: #powerpc, wuzish Subscribers: wuzish, kbarton, MaskRay, shchenz, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66748 llvm-svn: 370912
* [PowerPC][Altivec] Fix constant argument for vec_dssJinsong Ji2019-09-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is similar to vec_ct* in https://reviews.llvm.org/rL304205. The argument must be a constant, otherwise instruction selection will fail. always_inline is not enough for isel to always fold everything away at -O0. The fix is to turn the function into macros in altivec.h. Fixes https://bugs.llvm.org/show_bug.cgi?id=43072 Reviewers: nemanjai, hfinkel, #powerpc, wuzish Reviewed By: #powerpc, wuzish Subscribers: wuzish, kbarton, MaskRay, shchenz, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66699 llvm-svn: 370902
OpenPOWER on IntegriCloud