summaryrefslogtreecommitdiffstats
path: root/clang/test
Commit message (Collapse)AuthorAgeFilesLines
...
* [tooling] Teach Tooling to understand compilation with offloading.Michael Liao2019-10-101-0/+4
| | | | | | | | | | | | | | | | Summary: - So far, we only recognize the host compilation with offloading and skip the offloading part. Reviewers: tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68660 llvm-svn: 374470
* PR43629: Fix crash evaluating constexpr placement new on a subobject ofRichard Smith2019-10-101-0/+10
| | | | | | an out-of-lifetime object. llvm-svn: 374465
* Fix some errors in <arm_neon.h> tests that cause them to fail with laxRichard Smith2019-10-102-10/+10
| | | | | | vector conversions disabled. llvm-svn: 374457
* 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-107-85/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1019-0/+5418
| | | | | | 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-103-77/+78
| | | | | | | | | | | | | | | | | | | | | 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
* Fix one more clang test which didn't have \5C in itReid Kleckner2019-10-101-1/+1
| | | | llvm-svn: 374418
* Update clang tests for new LLVM IR backslash printing in r374415Reid Kleckner2019-10-105-10/+10
| | | | llvm-svn: 374416
* Re-land "Use -fdebug-compilation-dir to form absolute paths in coverage ↵Reid Kleckner2019-10-101-0/+16
| | | | | | | | | | | | mappings" This reverts r374324 (git commit 62808631acceaa8b78f8ab9b407eb6b943ff5f77) I changed the test to not rely on finding the sequence "clang, test, CoverageMapping" in the CWD used to run the test. Instead it makes its own internal directory hierarchy of foo/bar/baz and looks for that. llvm-svn: 374403
* [OPENMP50]Support for declare variant directive for NVPTX target.Alexey Bataev2019-10-101-0/+158
| | | | | | | NVPTX does not support global aliases. Instead, we have to copy the full body of the variant function for the original function. llvm-svn: 374387
* In openFileForRead don't cache erroneous entries if the error relates to ↵Kousik Kumar2019-10-102-0/+28
| | | | | | | | | | | | | | | | | | | | 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
* [OPENMP50]Register vendor name only once in vendor context selector.Alexey Bataev2019-10-102-2/+2
| | | | | | | No need to store multiple copies of the same vendor names in the context selector, keep only single copy. llvm-svn: 374363
* Revert "[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator"Dmitri Gribenko2019-10-1019-344/+344
| | | | | | | This reverts commit r374240. It broke OCaml tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19014 llvm-svn: 374354
* Revert "Use -fdebug-compilation-dir to form absolute paths in coverage mappings"Kadir Cetinkaya2019-10-101-16/+0
| | | | | | | | | | | | This reverts commit f6777964bde28c349d3e289ea37ecf5f5eeedbc4. Because the absolute path check relies on temporary path containing "clang", "test" and "CoverageMapping" as a subsequence, which is not necessarily true on all systems(breaks internal integrates). Wanted to fix it by checking for a leading "/" instead, but then noticed that it would break windows tests, so leaving it to the author instead. llvm-svn: 374324
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-109-193/+1051
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293
* Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)"Sjoerd Meijer2019-10-102-9/+30
| | | | | | | | | | | | | | | | | | | | | | | This was further discussed at the llvm dev list: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135602.html I think the brief summary of that is that this change is an improvement, this is the behaviour that we expect and promise in ours docs, and also as a result there are cases where we now emit diagnostics whereas before pragmas were silently ignored. Two areas where we can improve: 1) the diagnostic message itself, and 2) and in some cases (e.g. -Os and -Oz) the vectoriser is (quite understandably) not triggering. Original commit message: Specifying the vectorization width was supposed to implicitly enable vectorization, except that it wasn't really doing this. It was only setting the vectorize.width metadata, but not vectorize.enable. This should fix PR27643. llvm-svn: 374288
* [clang] prevent crash for nonnull attribut in constant context (Bug 43601)Gauthier Harnisch2019-10-101-3/+4
| | | | | | | | | | | | | | | | | | Summary: bug : https://bugs.llvm.org/show_bug.cgi?id=43601 Reviewers: rnk Reviewed By: rnk Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68716 llvm-svn: 374285
* Re-land [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-2/+8
| | | | | | | | | | | This reverts r374268 (git commit c34385d07c7d59447bf836b740f032235391d121) I think I reverted this by mistake, so I'm relanding it. While my bisect found this revision, I think the crashes I'm seeing locally must be environmental. Maybe the version of clang I'm using miscompiles tot clang. llvm-svn: 374269
* Revert [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-8/+2
| | | | | | | | This reverts r374200 (git commit fd18e94697c987d5f24e25aa4e27adaffff3cce4) Causes crashes just compiling `int main() {}` on my machine. llvm-svn: 374268
* Use -fdebug-compilation-dir to form absolute paths in coverage mappingsReid Kleckner2019-10-101-0/+16
| | | | | | | | | | | | | This allows users to explicitly request relative paths with `-fdebug-compilation-dir .`. Fixes PR43614 Reviewers: vsk, arphaman Differential Revision: https://reviews.llvm.org/D68733 llvm-svn: 374266
* [CUDA][HIP] Fix host/device check with -fopenmpYaxun Liu2019-10-096-3/+87
| | | | | | | | | | | | | | | | 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
* [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally2019-10-0919-344/+344
| | | | | | | | Also update Clang to call Builder.CreateFNeg(...) for UnaryMinus. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374240
* [OPENMP50]Fix scoring of contexts with and without user provided scores.Alexey Bataev2019-10-091-2/+2
| | | | | | | The context selector with user provided score must have higher score than the context selector without user provided score. llvm-svn: 374224
* [Clang][OpenMP Offload] Add new tool for wrapping offload device binariesSergey Dmitriev2019-10-093-120/+155
| | | | | | | | | | 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-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [HIP] Fix -save-tempsYaxun Liu2019-10-091-0/+41
| | | | | | | | | | Currently clang does not save some of the intermediate file generated during device compilation for HIP when -save-temps is specified. This patch fixes that. Differential Revision: https://reviews.llvm.org/D68665 llvm-svn: 374198
* [ARM] Fix arm_neon.h with -flax-vector-conversions=noneEli Friedman2019-10-0911-601/+199
| | | | | | | | | | | | | | Really, we were already 99% of the way there; just needed a couple minor fixes that affected 64-bit-only builtins. Based on D61717. Note that the change to builtin_str changes the type of a few __builtin_neon_* intrinsics that had the "wrong" type. Fixes https://bugs.llvm.org/show_bug.cgi?id=43341 Differential Revision: https://reviews.llvm.org/D68683 llvm-svn: 374191
* [WebAssembly] Add builtin and intrinsic for v8x16.swizzleThomas Lively2019-10-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | 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
* [mips] Set default float ABI to "soft" on FreeBSDSimon Atanasyan2019-10-091-0/+8
| | | | | | | | Initial patch by Kyle Evans. Fix PR43596 llvm-svn: 374154
* [DebugInfo] Enable call site debug info for ARM and AArch64Nikola Prica2019-10-091-0/+4
| | | | | | | | | | | | | | | | | ARM and AArch64 SelectionDAG support for tacking parameter forwarding register is implemented so we can allow clang invocations for those two targets. Beside that restrict debug entry value support to be emitted for LimitedDebugInfo info and FullDebugInfo. Other types of debug info do not have functions nor variables debug info. Reviewers: aprantl, probinson, dstenb, vsk Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D67004 llvm-svn: 374153
* [Sema] Emit diagnostics for uncorrected delayed typos at the end of TUIlya Biryukov2019-10-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of asserting all typos are corrected in the sema destructor. The sema destructor is not run in the common case of running the compiler with the -disable-free cc1 flag (which is the default in the driver). Having this assertion led to crashes in libclang and clangd, which are not reproducible when running the compiler. Asserting at the end of the TU could be an option, but finding all missing typo correction cases is hard and having worse diagnostics instead of a failing assertion is a better trade-off. For more discussion on this, see: https://lists.llvm.org/pipermail/cfe-dev/2019-July/062872.html Reviewers: sammccall, rsmith Reviewed By: rsmith Subscribers: usaxena95, dgoldman, jkorous, vsapsai, rnk, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64799 llvm-svn: 374152
* Revert r374006: Reland 'Add VFS support for sanitizers' blacklist'Ilya Biryukov2019-10-092-51/+0
| | | | | | | | | | | Also revert follow-up changes to the test. Reason: the patch breaks our internal clang-tidy integration. It's also unclear why we should use getRealPath instead of plumbing the VFS to SanitizerBlacklist, see original commit thread of cfe-commits for a discussion. llvm-svn: 374151
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-091-13/+36
| | | | | | | | | | | | 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-091-1/+68
| | | | | | | | | | | | | | 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
* [IRGen] Emit lifetime markers for temporary struct allocasFrancis Visoiu Mistrih2019-10-081-0/+89
| | | | | | | | | | | | | | When passing arguments using temporary allocas, we need to add the appropriate lifetime markers so that the stack coloring passes can re-use the stack space. This patch keeps track of all the lifetime.start calls emited before the codegened call, and adds the corresponding lifetime.end calls after the call. Differential Revision: https://reviews.llvm.org/D68611 llvm-svn: 374126
* Fix crash or wrong code bug if a lifetime-extended temporary contains aRichard Smith2019-10-081-0/+18
| | | | | | | | | | | | | | "non-constant" value. If the constant evaluator evaluates part of a variable initializer, including the initializer for some lifetime-extended temporary, but fails to fully evaluate the initializer, it can leave behind wrong values for temporaries encountered in that initialization. Don't try to emit those from CodeGen! Instead, look at the values that constant evaluation produced if (and only if) it actually succeeds and we're emitting the lifetime-extending declaration's initializer as a constant. llvm-svn: 374119
* [clang] Add llvm-ifs in test depsVitaly Buka2019-10-081-0/+1
| | | | llvm-svn: 374110
* [OPENMP50]Multiple vendors in vendor context must be treated as logicalAlexey Bataev2019-10-083-6/+10
| | | | | | | | | | | | | 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
* Try to get ubsan-blacklist-vfs.c pass more on WindowsNico Weber2019-10-081-2/+2
| | | | llvm-svn: 374105
* [BPF] do compile-once run-everywhere relocation for bitfieldsYonghong Song2019-10-083-0/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Attempt to make ubsan-blacklist-vfs test pass on WindowsJan Korous2019-10-081-4/+2
| | | | | | Previously disabled in d0c2d5daa3e llvm-svn: 374098
* [driver][hip] Skip bundler if host action is nothing.Michael Liao2019-10-081-0/+11
| | | | | | | | | | | | Reviewers: sfantao, tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68652 llvm-svn: 374097
* [OPENMP50]Do not allow multiple same context traits in the same contextAlexey Bataev2019-10-084-14/+16
| | | | | | | | | | 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-084-25/+14
| | | | | | | | 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-0817-69/+158
| | | | | | | | | | | | | | | | | | | | | | | 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-083-12/+31
| | | | | | | | | | C linkage. After some discussion with OpenMP developers, it was decided that the functions with the different C linkage can be used in declare variant directive. llvm-svn: 374057
* [Diagnostics] Silence -Wsizeof-array-div for character buffersJames Clarke2019-10-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Character buffers are sometimes used to represent a pool of memory that contains non-character objects, due to them being synonymous with a stream of bytes on almost all modern architectures. Often, when interacting with hardware devices, byte buffers are therefore used as an intermediary and so we can end Character buffers are sometimes used to represent a pool of memory that contains non-character objects, due to them being synonymous with a stream of bytes on almost all modern architectures. Often, when interacting with hardware devices, byte buffers are therefore used as an intermediary and so we can end up generating lots of false-positives. Moreover, due to the ability of character pointers to alias non-character pointers, the strict aliasing violations that would generally be implied by the calculations caught by the warning (if the calculation itself is in fact correct) do not apply here, and so although the length calculation may be wrong, that is the only possible issue. Reviewers: rsmith, xbolva00, thakis Reviewed By: xbolva00, thakis Subscribers: thakis, lebedev.ri, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68526 llvm-svn: 374035
OpenPOWER on IntegriCloud