summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenFunction.h
Commit message (Collapse)AuthorAgeFilesLines
...
* [ubsan] Add helpers to decide when null/vptr checks are required. NFC.Vedant Kumar2017-10-031-0/+6
| | | | llvm-svn: 314750
* [CodeGen] Do not refer to complete TBAA info where we actually deal with ↵Ivan A. Kosarev2017-10-021-5/+5
| | | | | | | | | | | | | | just TBAA access types This patch fixes misleading names of entities related to getting, setting and generation of TBAA access type descriptors. This is effectively an attempt to provide a review for D37826 by breaking it into smaller pieces. Differential Revision: https://reviews.llvm.org/D38404 llvm-svn: 314657
* [OPENMP] Generate implicit map|firstprivate clauses for target-basedAlexey Bataev2017-09-261-0/+3
| | | | | | | | | | directives. If the variable is used in the target-based region but is not found in any private|mapping clause, then generate implicit firstprivate|map clauses for these implicitly mapped variables. llvm-svn: 314205
* [CodeGen][ObjC] Build the global block structure before emitting theAkira Hatanaka2017-09-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | body of global block invoke functions. This commit fixes an infinite loop in IRGen that occurs when compiling the following code: void FUNC2() { static void (^const block1)(int) = ^(int a){ if (a--) block1(a); }; } This is how IRGen gets stuck in the infinite loop: 1. GenerateBlockFunction is called to emit the body of "block1". 2. GetAddrOfGlobalBlock is called to get the address of "block1". The function calls getAddrOfGlobalBlockIfEmitted to check whether the global block has been emitted. If it hasn't been emitted, it then tries to emit the body of the block function by calling GenerateBlockFunction, which goes back to step 1. This commit prevents the inifinite loop by building the global block in GenerateBlockFunction before emitting the body of the block function. rdar://problem/34541684 Differential Revision: https://reviews.llvm.org/D38118 llvm-svn: 314029
* [OPENMP] Handle re-declaration of captured variables in CodeGen.Alexey Bataev2017-09-221-3/+3
| | | | | | | | | If the captured variable has re-declaration we may end up with the situation where the captured variable is the re-declaration while the referenced variable is the canonical declaration (or vice versa). In this case we may generate wrong code. Patch fixes this situation. llvm-svn: 313995
* [ubsan] Function Sanitizer: Don't require writable text segmentsVedant Kumar2017-09-131-0/+9
| | | | | | | | | | | | | | | | | | This change will make it possible to use -fsanitize=function on Darwin and possibly on other platforms. It fixes an issue with the way RTTI is stored into function prologue data. On Darwin, addresses stored in prologue data can't require run-time fixups and must be PC-relative. Run-time fixups are undesirable because they necessitate writable text segments, which can lead to security issues. And absolute addresses are undesirable because they break PIE mode. The fix is to create a private global which points to the RTTI, and then to encode a PC-relative reference to the global into prologue data. Differential Revision: https://reviews.llvm.org/D37597 llvm-svn: 313096
* Updated two annotations for Store.h and CodeGenFunction.h.Krasimir Georgiev2017-09-081-2/+1
| | | | | | | | | | | | | | | | | | Summary: 1.Updated annotations for include/clang/StaticAnalyzer/Core/PathSensitive/Store.h, which belong to the old version of clang. 2.Delete annotations for CodeGenFunction::getEvaluationKind() in clang/lib/CodeGen/CodeGenFunction.h, which belong to the old version of clang. Reviewers: bkramer, krasimir, klimek Reviewed By: bkramer Subscribers: MTC Differential Revision: https://reviews.llvm.org/D36330 Contributed by @MTC! llvm-svn: 312790
* Debug info: Fixed faulty debug locations for attributed statementsKarl-Johan Karlsson2017-09-061-1/+1
| | | | | | | | | | | | | | | | | Summary: As the attributed statements are considered simple statements no stoppoint was generated before emitting attributed do/while/for/range- statement. This lead to faulty debug locations. Reviewers: echristo, aaron.ballman, dblaikie Reviewed By: dblaikie Subscribers: bjope, aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D37428 llvm-svn: 312623
* [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with Erich Keane2017-09-011-0/+4
| | | | | | | | | | | | | | | | | | | | "target" implementation A small set of refactors that'll make it easier for me to implement 'target' support. First, extract the CPUSupports functionality into its own function. THis has the advantage of not wasting time in this builtin to deal with arguments. Second, pulls both CPUSupports and CPUIs implementation into a member-function, so that it can be called from the resolver generation that I'm working on. Third, creates an overload that takes simply the feature/cpu name (rather than extracting it from a callexpr), since that info isn't available later. Note that despite how the 'diff' looks, the EmitX86CPUSupports function simply takes the implementation out of the 'switch'. llvm-svn: 312355
* [IRGen] Evaluate constant static variables referenced through memberAlex Lorenz2017-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions C++ allows us to reference static variables through member expressions. Prior to this commit, non-integer static variables that were referenced using a member expression were always emitted using lvalue loads. The old behaviour introduced an inconsistency between regular uses of static variables and member expressions uses. For example, the following program compiled and linked successfully: struct Foo { constexpr static const char *name = "foo"; }; int main() { return Foo::name[0] == 'f'; } but this program failed to link because "Foo::name" wasn't found: struct Foo { constexpr static const char *name = "foo"; }; int main() { Foo f; return f.name[0] == 'f'; } This commit ensures that constant static variables referenced through member expressions are emitted in the same way as ordinary static variable references. rdar://33942261 Differential Revision: https://reviews.llvm.org/D36876 llvm-svn: 311772
* [OPENMP] Fix for PR34014: OpenMP 4.5: Target construct in static methodAlexey Bataev2017-08-221-0/+2
| | | | | | | | | | of class fails to map class static variable. If the global variable is captured and it has several redeclarations, sometimes it may lead to a compiler crash. Patch fixes this by working only with canonical declarations. llvm-svn: 311479
* [OPENMP] Fix for PR28581: OpenMP linear clause - wrong results.Alexey Bataev2017-08-161-1/+3
| | | | | | | | | | If worksharing construct has at least one linear item, an implicit synchronization point must be emitted to avoid possible conflict with the loading/storing values to the original variables. Added implicit barrier if the linear item is found before actual start of the worksharing construct. llvm-svn: 311013
* Clean up some lambda conversion operator code, NFCReid Kleckner2017-08-041-2/+1
| | | | | | | | | | | | | | We don't need special handling in CodeGenFunction::GenerateCode for lambda block pointer conversion operators anymore. The conversion operator emission code immediately calls back to the generic EmitFunctionBody. Rename EmitLambdaStaticInvokeFunction to EmitLambdaStaticInvokeBody for better consistency with the other Emit*Body methods. I'm preparing to do something about PR28299, which touches this code. llvm-svn: 310145
* [ubsan] Diagnose invalid uses of builtins (clang)Vedant Kumar2017-07-291-0/+12
| | | | | | | | | | | | | | | On some targets, passing zero to the clz() or ctz() builtins has undefined behavior. I ran into this issue while debugging UB in __hash_table from libcxx: the bug I was seeing manifested itself differently under -O0 vs -Os, due to a UB call to clz() (see: libcxx/r304617). This patch introduces a check which can detect UB calls to builtins. llvm.org/PR26979 Differential Revision: https://reviews.llvm.org/D34590 llvm-svn: 309459
* Fix double destruction of objects when OpenMP construct is canceledErich Keane2017-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an omp for loop is canceled the constructed objects are being destructed twice. It looks like the desired code is: { Obj o; If (cancelled) branch-through-cleanups to cancel.exit. } [cleanups] cancel.exit: __kmpc_for_static_fini br cancel.cont (*) cancel.cont: __kmpc_barrier return The problem seems to be the branch to cancel.cont is currently also going through the cleanups calling them again. This change just does a direct branch instead. Patch By: michael.p.rice@intel.com Differential Revision: https://reviews.llvm.org/D35854 llvm-svn: 309288
* Add branch weights to branches for static initializers.Richard Smith2017-07-261-0/+8
| | | | | | | | | | | | | | | | | | | The initializer for a static local variable cannot be hot, because it runs at most once per program. That's not quite the same thing as having a low branch probability, but under the assumption that the function is invoked many times, modeling this as a branch probability seems reasonable. For TLS variables, the situation is less clear, since the initialization side of the branch can run multiple times in a program execution, but we still expect initialization to be rare relative to non-initialization uses. It would seem worthwhile to add a PGO counter along this path to make this estimation more accurate in future. For globals with guarded initialization, we don't yet apply any branch weights. Due to our use of COMDATs, the guard will be reached exactly once per DSO, but we have no idea how many DSOs will define the variable. llvm-svn: 309195
* [ubsan] Teach the pointer overflow check that "p - <unsigned> <= p" (PR33430)Vedant Kumar2017-07-131-0/+7
| | | | | | | | | | | | | | | | | | | | | The pointer overflow check gives false negatives when dealing with expressions in which an unsigned value is subtracted from a pointer. This is summarized in PR33430 [1]: ubsan permits the result of the subtraction to be greater than "p", but it should not. To fix the issue, we should track whether or not the pointer expression is a subtraction. If it is, and the indices are unsigned, we know to expect "p - <unsigned> <= p". I've tested this by running check-{llvm,clang} with a stage2 ubsan-enabled build. I've also added some tests to compiler-rt, which are in D34122. [1] https://bugs.llvm.org/show_bug.cgi?id=33430 Differential Revision: https://reviews.llvm.org/D34121 llvm-svn: 307955
* [Sema] Mark a virtual CXXMethodDecl as used if a call to it can beAkira Hatanaka2017-07-131-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devirtualized. The code to detect devirtualized calls is already in IRGen, so move the code to lib/AST and make it a shared utility between Sema and IRGen. This commit fixes a linkage error I was seeing when compiling the following code: $ cat test1.cpp struct Base { virtual void operator()() {} }; template<class T> struct Derived final : Base { void operator()() override {} }; Derived<int> *d; int main() { if (d) (*d)(); return 0; } rdar://problem/33195657 Differential Revision: https://reviews.llvm.org/D34301 llvm-svn: 307883
* CodeGen: Fix address space of global variableYaxun Liu2017-07-081-4/+3
| | | | | | | | | | | | | Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
* [ubsan] Improve diagnostics for return value checks (clang)Vedant Kumar2017-06-231-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes ubsan's nonnull return value diagnostics more precise, which makes the diagnostics more useful when there are multiple return statements in a function. Example: 1 |__attribute__((returns_nonnull)) char *foo() { 2 | if (...) { 3 | return expr_which_might_evaluate_to_null(); 4 | } else { 5 | return another_expr_which_might_evaluate_to_null(); 6 | } 7 |} // <- The current diagnostic always points here! runtime error: Null returned from Line 7, Column 2! With this patch, the diagnostic would point to either Line 3, Column 5 or Line 5, Column 5. This is done by emitting source location metadata for each return statement in a sanitized function. The runtime is passed a pointer to the appropriate metadata so that it can prepare and deduplicate reports. Compiler-rt patch (with more tests): https://reviews.llvm.org/D34298 Differential Revision: https://reviews.llvm.org/D34299 llvm-svn: 306163
* CodeGen: Cast temporary variable to proper address spaceYaxun Liu2017-06-191-8/+34
| | | | | | | | | | | | | | | | In C++ all variables are in default address space. Previously change has been made to cast automatic variables to default address space. However that is not sufficient since all temporary variables need to be casted to default address space. This patch casts all temporary variables to default address space except those for passing indirect arguments since they are only used for load/store. This patch only affects target having non-zero alloca address space. Differential Revision: https://reviews.llvm.org/D33706 llvm-svn: 305711
* [coroutines] Allow co_await and co_yield expressions that return an lvalue ↵Eric Fiselier2017-06-151-0/+2
| | | | | | | | | | | | | | | | | | to compile Summary: The title says it all. Reviewers: GorNishanov, rsmith Reviewed By: GorNishanov Subscribers: rjmccall, cfe-commits Differential Revision: https://reviews.llvm.org/D34194 llvm-svn: 305496
* [ubsan] Detect invalid unsigned pointer index expression (clang)Vedant Kumar2017-06-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Adding an unsigned offset to a base pointer has undefined behavior if the result of the expression would precede the base. An example from @regehr: int foo(char *p, unsigned offset) { return p + offset >= p; // This may be optimized to '1'. } foo(p, -1); // UB. This patch extends the pointer overflow check in ubsan to detect invalid unsigned pointer index expressions. It changes the instrumentation to only permit non-negative offsets in pointer index expressions when all of the GEP indices are unsigned. Testing: check-llvm, check-clang run on a stage2, ubsan-instrumented build. Differential Revision: https://reviews.llvm.org/D33910 llvm-svn: 305216
* [ubsan] Add a check for pointer overflow UBVedant Kumar2017-06-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check pointer arithmetic for overflow. For some more background on this check, see: https://wdtz.org/catching-pointer-overflow-bugs.html https://reviews.llvm.org/D20322 Patch by Will Dietz and John Regehr! This version of the patch is different from the original in a few ways: - It introduces the EmitCheckedInBoundsGEP utility which inserts checks when the pointer overflow check is enabled. - It does some constant-folding to reduce instrumentation overhead. - It does not check some GEPs in CGExprCXX. I'm not sure that inserting checks here, or in CGClass, would catch many bugs. Possible future directions for this check: - Introduce CGF.EmitCheckedStructGEP, to detect overflows when accessing structures. Testing: Apart from the added lit test, I ran check-llvm and check-clang with a stage2, ubsan-instrumented clang. Will and John have also done extensive testing on numerous open source projects. Differential Revision: https://reviews.llvm.org/D33305 llvm-svn: 304459
* Restore and update documentation comment for EmitPointerWithAlignmentKrzysztof Parzyszek2017-05-191-5/+16
| | | | llvm-svn: 303419
* CodeGenFunction::EmitPointerWithAlignment(): Prune a \param in r303358, ↵NAKAMURA Takumi2017-05-191-15/+0
| | | | | | possibly obsolete. [-Wdocumentation] llvm-svn: 303414
* [CodeGen] Propagate LValueBaseInfo instead of AlignmentSourceKrzysztof Parzyszek2017-05-181-14/+17
| | | | | | | | | | | | | The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information about possible unrestricted aliasing. A new class LValueBaseInfo will contain both AlignmentSource and MayAlias info. This patch should not introduce any functional changes. Differential Revision: https://reviews.llvm.org/D33284 llvm-svn: 303358
* [OpenCL] Add intel_reqd_sub_group_size attribute supportXiuli Pan2017-05-041-10/+2
| | | | | | | | | | | | | | | | Summary: Add intel_reqd_sub_group_size attribute support as intel extension cl_intel_required_subgroup_size from https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt Reviewers: Anastasia, bader, hfinkel, pxli168 Reviewed By: Anastasia, bader, pxli168 Subscribers: cfe-commits, yaxunl Differential Revision: https://reviews.llvm.org/D30805 llvm-svn: 302125
* Adapt to LLVM's rename of WeakVH to WeakTrackingVH; NFCSanjoy Das2017-05-011-3/+4
| | | | llvm-svn: 301815
* [CodeGen][ObjC] Don't retain captured Objective-C pointers at blockAkira Hatanaka2017-04-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | creation that are const-qualified. When a block captures an ObjC object pointer, clang retains the pointer to prevent prematurely destroying the object the pointer points to before the block is called or copied. When the captured object pointer is const-qualified, we can avoid emitting the retain/release pair since the pointer variable cannot be modified in the scope in which the block literal is introduced. For example: void test(const id x) { callee(^{ (void)x; }); } This patch implements that optimization. rdar://problem/28894510 Differential Revision: https://reviews.llvm.org/D32601 llvm-svn: 301667
* Revert "Update to LLVM's use of WeakTrackingVH; NFC"Sanjoy Das2017-04-261-4/+3
| | | | | | This reverts commit r301427. llvm-svn: 301430
* Update to LLVM's use of WeakTrackingVH; NFCSanjoy Das2017-04-261-3/+4
| | | | | | | | | | | | Summary: Depends on D32266 Reviewers: davide, dblaikie Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32270 llvm-svn: 301427
* Recommit ofCarlo Bertolli2017-04-251-16/+80
| | | | | | | | | | | | | | [OpenMP] Initial implementation of code generation for pragma 'distribute parallel for' on host https://reviews.llvm.org/D29508 This patch makes the following additions: It abstracts away loop bound generation code from procedures associated with pragma 'for' and loops in general, in such a way that the same procedures can be used for 'distribute parallel for' without the need for a full re-implementation. It implements code generation for 'distribute parallel for' and adds regression tests. It includes tests for clauses. It is important to notice that most of the clauses are implemented as part of existing procedures. For instance, firstprivate is already implemented for 'distribute' and 'for' as separate pragmas. As the implementation of 'distribute parallel for' is based on the same procedures, then we automatically obtain implementation for such clauses without the need to add new code. However, this requires regression tests that verify correctness of produced code. llvm-svn: 301340
* Revert r301223Carlo Bertolli2017-04-241-80/+16
| | | | llvm-svn: 301233
* [OpenMP] Initial implementation of code generation for pragma 'distribute ↵Carlo Bertolli2017-04-241-16/+80
| | | | | | | | | | | | | | | | | parallel for' on host https://reviews.llvm.org/D29508 This patch makes the following additions: 1. It abstracts away loop bound generation code from procedures associated with pragma 'for' and loops in general, in such a way that the same procedures can be used for 'distribute parallel for' without the need for a full re-implementation. 2. It implements code generation for 'distribute parallel for' and adds regression tests. It includes tests for clauses. It is important to notice that most of the clauses are implemented as part of existing procedures. For instance, firstprivate is already implemented for 'distribute' and 'for' as separate pragmas. As the implementation of 'distribute parallel for' is based on the same procedures, then we automatically obtain implementation for such clauses without the need to add new code. However, this requires regression tests that verify correctness of produced code. Looking forward to comments. llvm-svn: 301223
* [ubsan] Reduce alignment checking of C++ object pointersVedant Kumar2017-04-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert an alignment check for the 'this' pointer at the start of each method/lambda. This allows clang to emit significantly fewer alignment checks overall, because if 'this' is aligned, so are its fields. This is essentially the same thing r295515 does, but for the alignment check instead of the null check. One difference is that we keep the alignment checks on member expressions where the base is a DeclRefExpr. There's an opportunity to diagnose unaligned accesses in this situation (as pointed out by Eli, see PR32630). Testing: check-clang, check-ubsan, and a stage2 ubsan build. Along with the patch from D30285, this roughly halves the amount of alignment checks we emit when compiling X86FastISel.cpp. Here are the numbers from patched/unpatched clangs based on r298160. ------------------------------------------ | Setup | # of alignment checks | ------------------------------------------ | unpatched, -O0 | 24326 | | patched, -O0 | 12717 | (-47.7%) ------------------------------------------ Differential Revision: https://reviews.llvm.org/D30283 llvm-svn: 300370
* [cfi] Emit __cfi_check stub in the frontend.Evgeniy Stepanov2017-04-071-0/+3
| | | | | | | | | Previously __cfi_check was created in LTO optimization pipeline, which means LLD has no way of knowing about the existence of this symbol without rescanning the LTO output object. As a result, LLD fails to export __cfi_check, even when given --export-dynamic-symbol flag. llvm-svn: 299806
* Clang changes for alloc_align attribute Erich Keane2017-03-301-0/+6
| | | | | | | | GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to. Differential Revision: https://reviews.llvm.org/D29599 llvm-svn: 299117
* [coroutines] Add codegen for await and yield expressionsGor Nishanov2017-03-261-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Details: Emit suspend expression which roughly looks like: auto && x = CommonExpr(); if (!x.await_ready()) { llvm_coro_save(); x.await_suspend(...); (*) llvm_coro_suspend(); (**) } x.await_resume(); where the result of the entire expression is the result of x.await_resume() (*) If x.await_suspend return type is bool, it allows to veto a suspend: if (x.await_suspend(...)) llvm_coro_suspend(); (**) llvm_coro_suspend() encodes three possible continuations as a switch instruction: %where-to = call i8 @llvm.coro.suspend(...) switch i8 %where-to, label %coro.ret [ ; jump to epilogue to suspend i8 0, label %yield.ready ; go here when resumed i8 1, label %yield.cleanup ; go here when destroyed ] llvm-svn: 298784
* [ubsan] Use the nicer nullability diagnostic handlersVedant Kumar2017-03-141-1/+5
| | | | | | | | | | | This is a follow-up to r297700 (Add a nullability sanitizer). It addresses some FIXME's re: using nullability-specific diagnostic handlers from compiler-rt, now that the necessary handlers exist. check-ubsan test updates to follow. llvm-svn: 297750
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* Retry: [ubsan] Detect UB loads from bitfieldsVedant Kumar2017-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields. This is the motivating example: struct S { BOOL b : 1; // Signed ObjC BOOL. }; S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ... Changes since the original commit: - Single-bit bools are a special case (see CGF::EmitFromMemory), and we can't avoid dealing with them when loading from a bitfield. Don't try to insert a check in this case. Differential Revision: https://reviews.llvm.org/D30423 llvm-svn: 297389
* Revert "[ubsan] Detect UB loads from bitfields"Vedant Kumar2017-03-091-1/+1
| | | | | | | | This reverts commit r297298. It breaks the self-host on this bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/steps/build%20clang%2Fubsan/logs/stdio llvm-svn: 297331
* [ubsan] Detect UB loads from bitfieldsVedant Kumar2017-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields. This is the motivating example: struct S { BOOL b : 1; // Signed ObjC BOOL. }; S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ... Differential Revision: https://reviews.llvm.org/D30423 llvm-svn: 297298
* Don't assume cleanup emission preserves dominance in expr evaluationReid Kleckner2017-03-061-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
* [coroutines] Add co_return statement emissionGor Nishanov2017-03-061-0/+1
| | | | | | | | | | | | | | | | | Summary: Added co_return statement emission. Tweaked coro-alloc.cpp test to use co_return to trigger coroutine processing instead of co_await, since this change starts emitting the body of the coroutine and await expression handling has not been upstreamed yet. Reviewers: rsmith, majnemer, EricWF, aaron.ballman Reviewed By: rsmith Subscribers: majnemer, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D29979 llvm-svn: 297076
* [ubsan] Extend the nonnull arg check to ObjCVedant Kumar2017-03-061-4/+29
| | | | | | | | | | UBSan's nonnull argument check applies when a parameter has the "nonnull" attribute. The check currently works for FunctionDecls, but not for ObjCMethodDecls. This patch extends the check to work for ObjC. Differential Revision: https://reviews.llvm.org/D30599 llvm-svn: 296996
* [ubsan] Factor out logic to emit a range check. NFC.Vedant Kumar2017-02-271-0/+7
| | | | | | | This is a readability improvement, but it will also help prep an upcoming patch to detect UB loads from bitfields. llvm-svn: 296374
* Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 2nd attempt: the first was in r296231, but it had a use after lifetime bug. Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296245
* Revert "[profiling] Fix profile counter increment when emitting selects ↵Vedant Kumar2017-02-251-4/+3
| | | | | | | | | | | | | | | | | | | | | (PR32019)" This reverts commit r296231. It causes an assertion failure on 32-bit machines clang: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed. llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5fbfa) llvm::sys::RunSignalHandlers() (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dc7e) SignalHandler(int) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dde2) __restore_rt (/lib64/libpthread.so.0+0x3f1d00efa0) __GI_raise /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 __GI_abort /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/stdlib/abort.c:92:0 __assert_fail_base /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/assert/assert.c:92:0 (/lib64/libc.so.6+0x3f1c82e622) llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1804e3a) clang::CodeGen::CodeGenPGO::emitCounterIncrement(clang::CodeGen::CGBuilderTy&, clang::Stmt const*, llvm::Value*) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1ec7891) llvm-svn: 296234
OpenPOWER on IntegriCloud