summaryrefslogtreecommitdiffstats
path: root/clang/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-147-1/+111
| | | | | | | | | 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-141-0/+4
| | | | | | | | | | | 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
* [clang][IFS] Fixing spelling errors in interface-stubs OPT flag (NFC).Puyan Lotfi2019-10-121-2/+2
| | | | | | This is just a long standing spelling error that was found recently. llvm-svn: 374638
* [ObjC] Remove default parameter no caller was providing. NFC intended.Volodymyr Sapsai2019-10-111-2/+1
| | | | | | | | Currently there is no need to make ObjCTypeParamType have a canonical type different from the one in corresponding ObjCTypeParamDecl. So remove the corresponding unused API. llvm-svn: 374596
* [Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.Volodymyr Sapsai2019-10-112-12/+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 llvm-svn: 374581
* Update clang module map for new excluded .def file.Richard Smith2019-10-111-0/+1
| | | | llvm-svn: 374571
* 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 llvm-svn: 374562
* [libTooling] Move `RewriteRule` abstraction into its own header and impl.Yitzhak Mandelbaum2019-10-112-271/+291
| | | | | | | | | | | | | | | | | | | Summary: Move the `RewriteRule` class and related declarations into its own set of files (header, implementation). Only the `Transformer` class is left in the Transformer-named files. This change clarifies the distinction between the `RewriteRule` class, which is essential to the Transformer library, and the `Transformer` class, which is only one possible `RewriteRule` interpreter (compare to `TransformerClangTidyCheck`, a clang-tidy based interpreter). Reviewers: gribozavr Subscribers: jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68795 llvm-svn: 374558
* [libTooling] Change Stencil equality to use `toString()`Yitzhak Mandelbaum2019-10-111-24/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Removes the `isEqual` method from StencilPartInterface and modifies equality to use the string representation returned by the `toString` method for comparison. This means the `run` and `selection` stencils return true by default, and clients should be cautious in relying on equality operator for comparison of stencils containing parts generated by these functions. It also means we no longer need the custom RTTI support (typeId() and down_cast()), so it has been removed. Patch by Harshal T. Lehri. Reviewers: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68825 llvm-svn: 374552
* Dead Virtual Function EliminationOliver Stannard2019-10-112-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 374539
* Move most CXXRecordDecl::DefinitionData bit-fields out into a separateRichard Smith2019-10-112-204/+243
| | | | | | | | | | | file. Reduces duplication and thereby reduces the risk that someone will forget to update one of these places, as I did when adding DefaultedDestructorIsConstexpr (though I've been unable to produce a testcase for which that matters so far). llvm-svn: 374484
* Fix help message for -ffp-contractYaxun Liu2019-10-101-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D68823 llvm-svn: 374467
* PR43629: Fix crash evaluating constexpr placement new on a subobject ofRichard Smith2019-10-101-1/+2
| | | | | | an out-of-lifetime object. llvm-svn: 374465
* 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 llvm-svn: 374456
* 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 llvm-svn: 374450
* Add -fgnuc-version= to control __GNUC__ and other GCC macrosReid Kleckner2019-10-102-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 374449
* [OPENMP50]Support for 'master taskloop' directive.Alexey Bataev2019-10-107-1/+109
| | | | | | Added full support for master taskloop directive. llvm-svn: 374437
* [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 llvm-svn: 374419
* In openFileForRead don't cache erroneous entries if the error relates to ↵Kousik Kumar2019-10-101-0/+3
| | | | | | | | | | | | | | | | | | | | them being directories. Add tests. Summary: It seems that when the CachingFileSystem is first given a file to open that is actually a directory, it incorrectly caches that path to be errenous and throws an error when subsequently a directory open call is made for the same path. This change makes it so that we do NOT cache a path if it turns out we asked for a file when its a directory. Reviewers: arphaman Subscribers: dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68193 llvm-svn: 374366
* Remove rest of time-trace message as it is inconsistent styleRussell Gallop2019-10-101-1/+6
| | | | | | | | | Other options which create output files don't produce output messages. Improve documentation to help find trace file. Differential Revision: https://reviews.llvm.org/D68710 llvm-svn: 374294
* [ast] Fix indentation. NFC.Michael Liao2019-10-101-6/+2
| | | | llvm-svn: 374276
* [sema] Revise `getCurrentMangleNumberContext` interface. NFC.Michael Liao2019-10-101-6/+4
| | | | | | | - Prefer returning mulitple values using a tuple instead of additional pointers/references. llvm-svn: 374274
* [libTooling] Move Transformer files to their own directory/library.Yitzhak Mandelbaum2019-10-106-20/+20
| | | | | | | | | | | | | | | | | | | Summary: The Transformer library has been growing inside of lib/Tooling/Refactoring. However, it's not really related to anything else in that directory. This revision moves all Transformer-related files into their own include & lib directories. A followup revision will (temporarily) add forwarding headers to help any users migrate their code to the new location. Reviewers: gribozavr Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68637 llvm-svn: 374271
* Re-land [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-102-13/+6
| | | | | | | | | | | 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-102-6/+13
| | | | | | | | 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-091-0/+13
| | | | | | | | | | | | | | | | 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
* [Clang][OpenMP Offload] Add new tool for wrapping offload device binariesSergey Dmitriev2019-10-093-3/+15
| | | | | | | | | | This patch removes the remaining part of the OpenMP offload linker scripts which was used for inserting device binaries into the output linked binary. Device binaries are now inserted into the host binary with a help of the wrapper bit-code file which contains device binaries as data. Wrapper bit-code file is dynamically created by the clang driver with a help of new tool clang-offload-wrapper which takes device binaries as input and produces bit-code file with required contents. Wrapper bit-code is then compiled to an object and resulting object is appended to the host linking by the clang driver. This is the second part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943). Differential Revision: https://reviews.llvm.org/D68166 llvm-svn: 374219
* [ObjC generics] Fix not inheriting type bounds in categories/extensions.Volodymyr Sapsai2019-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a category/extension doesn't repeat a type bound, corresponding type parameter is substituted with `id` when used as a type argument. As a result, in the added test case it was causing errors like > type argument 'T' (aka 'id') does not satisfy the bound ('id<NSCopying>') of type parameter 'T' We are already checking that type parameters should be consistent everywhere (see `checkTypeParamListConsistency`) and update `ObjCTypeParamDecl` to have correct underlying type. And when we use the type parameter as a method return type or a method parameter type, it is substituted to the bounded type. But when we use the type parameter as a type argument, we check `ObjCTypeParamType` that ignores the updated underlying type and remains `id`. Fix by desugaring `ObjCTypeParamType` to the underlying type, the same way we are doing with `TypedefType`. rdar://problem/54329242 Reviewers: erik.pilkington, ahatanak Reviewed By: erik.pilkington Subscribers: jkorous, dexonsmith, ributzka, cfe-commits Differential Revision: https://reviews.llvm.org/D66696 llvm-svn: 374202
* [mangle] Fix mangling where an extra mangle context is required.Michael Liao2019-10-092-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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 llvm-svn: 374189
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-092-0/+11
| | | | | | | | | | | | 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-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. llvm-svn: 374133
* [clang] enable_trivial_var_init_zero should not be Joined<>Vitaly Buka2019-10-081-1/+1
| | | | | | | | | | | | Reviewers: rnk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68610 llvm-svn: 374113
* [OPENMP50]Multiple vendors in vendor context must be treated as logicalAlexey Bataev2019-10-082-7/+11
| | | | | | | | | | | | | 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-085-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]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. llvm-svn: 374093
* [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. llvm-svn: 374072
* [clang][ifs] Clang Interface Stubs ToolChain plumbing.Puyan Lotfi2019-10-085-2/+21
| | | | | | | | | | | | | | | | | | | | | | | Second Landing Attempt: This patch enables end to end support for generating ELF interface stubs directly from clang. Now the following: clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp will product an ELF binary with visible symbols populated. Visibility attributes and -fvisibility can be used to control what gets populated. * Adding ToolChain support for clang Driver IFS Merge Phase * Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain * Adds support for the clang Driver to involve llvm-ifs on ifs files. * Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file instead of the final object format (normally ELF) Differential Revision: https://reviews.llvm.org/D63978 llvm-svn: 374061
* [OPENMP50]Allow functions in declare variant directive to have differentAlexey Bataev2019-10-081-1/+1
| | | | | | | | | | 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
* [clang] Accept -ftrivial-auto-var-init in clang-clVitaly Buka2019-10-071-2/+2
| | | | | | | | | | | | Reviewers: eugenis, rnk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68608 llvm-svn: 373992
* [Diagnostics] Emit better -Wbool-operation's warning message if we known ↵David Bolvansky2019-10-071-1/+2
| | | | | | that the result is always true llvm-svn: 373973
* [OPENMP]Fix caonical->canonical, NFC.Alexey Bataev2019-10-071-2/+2
| | | | | | Fixed typo. llvm-svn: 373952
* [OPENMP50]Treat range-based for as canonical loop.Alexey Bataev2019-10-072-2/+19
| | | | | | | According to OpenMP 5.0, range-based for is also considered as a canonical form of loops. llvm-svn: 373939
* [libTooling] Add `toString` method to the Stencil classYitzhak Mandelbaum2019-10-071-0/+21
| | | | | | | | | | | | | | | | | Summary: `toString` generates a string representation of the stencil. Patch by Harshal T. Lehri. Reviewers: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68574 llvm-svn: 373916
* clang-cl: Ignore the new /ZH optionsHans Wennborg2019-10-071-0/+3
| | | | | | | | | These were added to the MS docs in https://github.com/MicrosoftDocs/cpp-docs/commit/85b9b6967e58e485251450f7451673f6fc873e88 and are supposedly available in VS 2019 16.4 (though my 2019 Preview, version 16.4.0-pre.1.0 don't seem to have them.) llvm-svn: 373887
* Fix behavior of __builtin_bit_cast when the From and To types are theRichard Smith2019-10-071-2/+3
| | | | | | | | | | same. We were missing the lvalue-to-rvalue conversion entirely in this case, and in fact still need the full CK_LValueToRValueBitCast conversion to perform a load with no TBAA. llvm-svn: 373874
* [NFCI] Slightly improve warning messageDavid Bolvansky2019-10-051-1/+1
| | | | llvm-svn: 373818
* [Sema] Split out -Wformat-type-confusion from -Wformat-pedanticErik Pilkington2019-10-043-5/+21
| | | | | | | | | 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
* Further improve -Wbool-operation bitwise negation messageSam McCall2019-10-041-1/+1
| | | | llvm-svn: 373749
* [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. llvm-svn: 373743
OpenPOWER on IntegriCloud