summaryrefslogtreecommitdiff
path: root/include/clang/Basic
Commit message (Collapse)AuthorAgeFilesLines
* Add -Wbitwise-conditional-parentheses to warn on mixing '|' and '&' with "?:"Richard Trieu2019-10-192-0/+5
| | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375326 91177308-0d34-0410-b5e6-96231b3b80d8
* New tautological warning for bitwise-or with non-zero constant always true.Richard Trieu2019-10-192-1/+6
| | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375318 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-192-1/+33
| | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375306 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-191-0/+1
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375305 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add support for master taskloop simd.Alexey Bataev2019-10-183-1/+31
| | | | | | Added trsing/semantics/codegen for combined construct master taskloop simd. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375255 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland: Dead Virtual Function EliminationOliver Stannard2019-10-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove dead virtual functions from vtables with replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up correctly. Original commit message: Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375094 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-151-2/+2
| | | | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374938 91177308-0d34-0410-b5e6-96231b3b80d8
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-152-2/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374934 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland [Driver] Fix -working-directory issuesJan Korous2019-10-151-0/+2
| | | | | | | | Don't change the default VFS in Driver, update tests & reland. This reverts commit 999f8a7416f8edc54ef92e715fd23c532bcc74d4. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374926 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-152-2/+12
| | | | | | | | | | | | 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) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374903 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-152-12/+2
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374899 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply: [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-151-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 llvm-svn: 374841 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374895 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-152-2/+12
| | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374882 91177308-0d34-0410-b5e6-96231b3b80d8
* [WebAssembly] Trapping fptoint builtins and intrinsicsThomas Lively2019-10-151-0/+10
| | | | | | | | | | | | | | | | | | | | | Summary: The WebAssembly backend lowers fptoint instructions to a code sequence that checks for overflow to avoid traps because fptoint is supposed to be speculatable. These new builtins and intrinsics give users a way to depend on the trapping semantics of the underlying instructions and avoid the extra code generated normally. Patch by coffee and tlively. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68902 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374856 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-141-4/+0
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374844 91177308-0d34-0410-b5e6-96231b3b80d8
* Temporarily Revert [Modules][PCH] Hash input files contentEric Christopher2019-10-141-8/+3
| | | | | | | | as it's breaking a few bots. This reverts r374841 (git commit 2a1386c81de504b5bda44fbecf3f7b4cdfd748fc) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374842 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-141-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374841 91177308-0d34-0410-b5e6-96231b3b80d8
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374826 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-142-0/+27
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374791 91177308-0d34-0410-b5e6-96231b3b80d8
* [Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.Volodymyr Sapsai2019-10-111-4/+0
| | | | | | | | | | | | | | | | | rdar://problem/55715134 Reviewers: dsanders, bogner, rtereshin Reviewed By: dsanders Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68252 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374581 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland r374450 with Richard Smith's comments and test fixed.Erich Keane2019-10-111-0/+4
| | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374562 91177308-0d34-0410-b5e6-96231b3b80d8
* Dead Virtual Function EliminationOliver Stannard2019-10-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374539 91177308-0d34-0410-b5e6-96231b3b80d8
* PR43629: Fix crash evaluating constexpr placement new on a subobject ofRichard Smith2019-10-101-1/+2
| | | | | | an out-of-lifetime object. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374465 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 374450 "Fix __builtin_assume_aligned with too large values."Nico Weber2019-10-101-4/+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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374456 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix __builtin_assume_aligned with too large values.Erich Keane2019-10-101-0/+4
| | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374450 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -fgnuc-version= to control __GNUC__ and other GCC macrosReid Kleckner2019-10-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that compiling on Windows with -fno-ms-compatibility had the side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and a number of other macros for GCC compatibility. This is undesirable and causes Chromium to do things like mix __attribute__ and __declspec, which doesn't work. We should have a positive language option to enable GCC compatibility features so that we can experiment with -fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be that option. My issue aside, users have, for a long time, reported that __GNUC__ doesn't match their expectations in one way or another. We have encouraged users to migrate code away from this macro, but new code continues to be written assuming a GCC-only environment. There's really nothing we can do to stop that. By adding this flag, we can allow them to choose their own adventure with __GNUC__. This overlaps a bit with the "GNUMode" language option from -std=gnu*. The gnu language mode tends to enable non-conforming behaviors that we'd rather not enable by default, but the we want to set things like __GXX_RTTI__ by default, so I've kept these separate. Helps address PR42817 Reviewed By: hans, nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D68055 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374449 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Support for 'master taskloop' directive.Alexey Bataev2019-10-102-0/+25
| | | | | | Added full support for master taskloop directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374437 91177308-0d34-0410-b5e6-96231b3b80d8
* [ARM] Fix arm_neon.h with -flax-vector-conversions=none, part 2.Eli Friedman2019-10-101-4/+4
| | | | | | | | | | | | | | | | | | | | | | | Just running -fsyntax-only over arm_neon.h doesn't cover some intrinsics which are defined using macros. Add more test coverage for that. arm-neon-header.c wasn't checking the full set of available NEON target features; change the target architecture of the test to account for that. Fix the generator for arm_neon.h to generate casts in more cases where they are necessary. Fix VFMLAL_LOW etc. to express their signatures differently, so the builtins have the expected type. Maybe the TableGen backend should detect intrinsics that are defined the wrong way, and produce an error. The rules here are sort of strange. Differential Revision: https://reviews.llvm.org/D68743 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374419 91177308-0d34-0410-b5e6-96231b3b80d8
* [WebAssembly] Add builtin and intrinsic for v8x16.swizzleThomas Lively2019-10-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: This clang builtin and corresponding LLVM intrinsic are necessary to expose the exact semantics of the underlying WebAssembly instruction to users. LLVM produces a poison value if the dynamic swizzle indices are greater than the vector size, but the WebAssembly instruction sets the corresponding output lane to zero. Users who depend on this behavior can safely use this builtin. Depends on D68527. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68531 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374189 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-091-0/+3
| | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374135 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Implement most of P1152R4.Richard Smith2019-10-092-0/+19
| | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374133 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Multiple vendors in vendor context must be treated as logicalAlexey Bataev2019-10-081-2/+6
| | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374107 91177308-0d34-0410-b5e6-96231b3b80d8
* [BPF] do compile-once run-everywhere relocation for bitfieldsYonghong Song2019-10-083-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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374099 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Do not allow multiple same context traits in the same contextAlexey Bataev2019-10-081-0/+5
| | | | | | | | | | selector. According to OpenMP 5.0, 2.3.2 Context Selectors, Restrictions, each trait-selector-name can only be specified once. Added check for this restriction. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374093 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Prohibit multiple context selector sets in context selectors.Alexey Bataev2019-10-081-0/+4
| | | | | | | | According to OpenMP 5.0, 2.3.2 Context Selectors, Restrictions, each trait-set-selector-name can only be specified once. Added check to implement this restriction. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374072 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Emit better -Wbool-operation's warning message if we known ↵David Bolvansky2019-10-071-1/+2
| | | | | | that the result is always true git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373973 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFCI] Slightly improve warning messageDavid Bolvansky2019-10-051-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373818 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Split out -Wformat-type-confusion from -Wformat-pedanticErik Pilkington2019-10-042-4/+6
| | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373774 91177308-0d34-0410-b5e6-96231b3b80d8
* Further improve -Wbool-operation bitwise negation messageSam McCall2019-10-041-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373749 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFCI] Improve the -Wbool-operation's warning messageDavid Bolvansky2019-10-041-1/+1
| | | | | | | | Based on the request from the post commit review. Also added one new test. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373743 91177308-0d34-0410-b5e6-96231b3b80d8
* Check for qualified function types after substituting into the operandRichard Smith2019-10-031-0/+2
| | | | | | | | | | of 'typeid'. This is a rare place where it's valid for a function type to be substituted but not valid for a qualified function type to be substituted, so needs a special check. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373648 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC] Added missing changes for rL373614David Bolvansky2019-10-031-0/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373616 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: support placement new-expressions in constant evaluation.Richard Smith2019-10-031-15/+29
| | | | | | | | | For now, we restrict this support to use from within the standard library implementation, since we're required to make parts of the standard library that use placement new work, but not permitted to make uses of placement new from user code work. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373547 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: allow direct calls to operator new / operator delete fromRichard Smith2019-10-031-2/+13
| | | | | | std::allocator::{allocate,deallocate} in constant evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373546 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add parsing/sema analysis for declare variant score.Alexey Bataev2019-10-021-0/+15
| | | | | | | | Context selectors may include optional score clause in format `score(<expr>):`, where `<expr>` must be a constant integer expression. Added parsing/sema analysis only. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373502 91177308-0d34-0410-b5e6-96231b3b80d8
* Emit TypeNodes.def with tblgen.John McCall2019-10-011-0/+106
| | | | | | | | | | | | | | | | | | The primary goal here is to make the type node hierarchy available to other tblgen backends, although it should also make it easier to generate more selective x-macros in the future. Because tblgen doesn't seem to allow backends to preserve the source order of defs, this is not NFC because it significantly re-orders IDs. I've fixed the one (fortunately obvious) place where we relied on the old order. Unfortunately, I wasn't able to share code with the existing AST-node x-macro generators because the x-macro schema we use for types is different in a number of ways. The main loss is that subclasses aren't ordered together, which doesn't seem important for types because the hierarchy is generally very shallow with little clustering. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373407 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Make -Wenum-compare-conditional off by defaultDavid Bolvansky2019-10-012-2/+2
| | | | | | | Too many false positives, eg. in Chromium. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373371 91177308-0d34-0410-b5e6-96231b3b80d8
* [Diagnostics] Move warning into the subgroup (-Wenum-compare-conditional)David Bolvansky2019-10-012-2/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373345 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Mark declare variant attribute as inheritable.Alexey Bataev2019-09-301-1/+2
| | | | | | Attribute must be inherited by the redeclarations. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373257 91177308-0d34-0410-b5e6-96231b3b80d8
* For now, disallow lifetime-extended temporaries with non-trivial (butRichard Smith2019-09-291-0/+3
| | | | | | | | | | | | constexpr) destructors from being used in the values of constexpr variables. The standard rules here are unclear at best, so rejecting the problematic cases seems prudent. Prior to this change, we would fail to run the destructors for these temporaries, even if they had side-effects, which is certainly not the right behavior. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373161 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status