[PATCH] D29369: [ubsan] Omit superflous overflow checks for promoted arithmetic (PR20193)

2017-02-01 Thread Vedant Kumar via Phabricator via cfe-commits
vsk updated this revision to Diff 86746. vsk edited the summary of this revision. vsk added a comment. - Remove a stale test case in unsigned-promotion.c. https://reviews.llvm.org/D29369 Files: lib/CodeGen/CGExprScalar.cpp test/CodeGen/compound-assign-overflow.c

[PATCH] D29369: [ubsan] Omit superflous overflow checks for promoted arithmetic (PR20193)

2017-02-01 Thread Vedant Kumar via Phabricator via cfe-commits
vsk updated this revision to Diff 86739. vsk marked an inline comment as done. vsk added a comment. - Per Eli's comment: check that integers are actually widened, instead of incorrectly assuming they are always widened. I added some test cases for this. - Address the 'fixme' regarding

[PATCH] D29369: [ubsan] Omit superflous overflow checks for promoted arithmetic (PR20193)

2017-02-01 Thread Vedant Kumar via Phabricator via cfe-commits
vsk marked an inline comment as done. vsk added inline comments. Comment at: lib/CodeGen/CGExprScalar.cpp:72 + if (const auto *UO = dyn_cast(Op.E)) +return IsPromotedInteger(UO->getSubExpr()); + efriedma wrote: > Checking isPromotableIntegerType doesn't

[PATCH] D29369: [ubsan] Omit superflous overflow checks for promoted arithmetic (PR20193)

2017-01-31 Thread Vedant Kumar via Phabricator via cfe-commits
vsk created this revision. C requires the operands of arithmetic expressions to be promoted if their types are smaller than an int. Ubsan emits overflow checks when this sort of type promotion occurs, even if there is no way to actually get an overflow with the promoted type. This patch teaches

[PATCH] D29234: [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)

2017-01-27 Thread Vedant Kumar via Phabricator via cfe-commits
vsk created this revision. Ubsan does not report UB shifts in some cases where the shift exponent needs to be truncated to match the type of the shift base. We perform a range check on the truncated shift amount, leading to false negatives. Fix the issue (PR27271) by performing the range check

[PATCH] D28867: [Profile] Warn about out-of-date profiles only when there are mismatches

2017-01-18 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added a comment. Ah ok, so it sounds like a better approach would be to split the missing record message into a separate off-by-default warning. I don't have the time to update this diff this week, but will shoot for the next. https://reviews.llvm.org/D28867

[PATCH] D28867: [Profile] Warn about out-of-date profiles only when there are mismatches

2017-01-18 Thread Vedant Kumar via Phabricator via cfe-commits
vsk created this revision. Clang warns that a profile is out-of-date if it can't find a profile record for any function in a TU. This warning is now noisy because llvm can dead-strip functions with profiling instrumentation. Only emit the out-of-date warning if there is an actual record

[PATCH] D28131: [libcxx] Fix PR31402: map::__find_equal_key has undefined behavior.

2016-12-29 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added a comment. LGTM. I'm not sure what to do for a test. Have you tried checking the IR for the affected object file in tablegen at '-O2 -fsanitize=undefined'? If there's an unconditional call to the ubsan handler, maybe the tablegen source could be used to find a small reproducer?

[PATCH] D27410: Always issue vtables when generating coverage instrumentation

2016-12-19 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added inline comments. Comment at: llvm/tools/clang/test/CodeGenCXX/vtable-coverage-gen.cpp:3 +// RUN: FileCheck %s < %t +// CHECK: @_ZTV8Category = linkonce_odr unnamed_addr constant {{.*}}, comdat, + vsk wrote: > ahatanak wrote: > > I'm not sure I

[PATCH] D27410: Always issue vtables when generating coverage instrumentation

2016-12-19 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added inline comments. Comment at: llvm/tools/clang/test/CodeGenCXX/vtable-coverage-gen.cpp:3 +// RUN: FileCheck %s < %t +// CHECK: @_ZTV8Category = linkonce_odr unnamed_addr constant {{.*}}, comdat, + ahatanak wrote: > I'm not sure I understood the purpose

[PATCH] D27607: [ubsan] Treat ObjC's BOOL as if its range is always {0, 1}

2016-12-09 Thread Vedant Kumar via Phabricator via cfe-commits
vsk updated this revision to Diff 80960. vsk marked 3 inline comments as done. vsk added a comment. - Use NSAPI's 'is-BOOL' predicate. - Simplify test. https://reviews.llvm.org/D27607 Files: lib/CodeGen/CGExpr.cpp test/CodeGenObjC/ubsan-bool.m Index: test/CodeGenObjC/ubsan-bool.m

[PATCH] D27607: [ubsan] Treat ObjC's BOOL as if its range is always {0, 1}

2016-12-09 Thread Vedant Kumar via Phabricator via cfe-commits
vsk marked 3 inline comments as done. vsk added a comment. Thanks for your feedback. I will updated the patch shortly. Comment at: lib/CodeGen/CGExpr.cpp:1221 +/// Check if \p Ty is defined as BOOL in a system header. In ObjC language +/// modes, it's safe to treat such a type

[PATCH] D27607: [ubsan] Treat ObjC's BOOL as if its range is always {0, 1}

2016-12-09 Thread Vedant Kumar via Phabricator via cfe-commits
vsk created this revision. vsk added a reviewer: ahatanak. vsk added subscribers: kubabrecka, cfe-commits. On some Apple platforms, the ObjC BOOL type is defined as a signed char. When performing instrumentation for -fsanitize=bool, we'd like to treat the range of BOOL like it's always {0, 1}.

[PATCH] D27180: Testbed and skeleton of a new expression parser

2016-11-30 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added a comment. Looks good. Apart from some nitpicks, I'm happy with this. This isn't really my area so it'd be good to get an explicit lgtm from one of the reviewers. Comment at: tools/clang-import-test/CMakeLists.txt:7 + clang-import-test.cpp + ) +

[PATCH] D27180: Testbed and skeleton of a new expression parser

2016-11-29 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added a comment. Thanks for working on this! I'm happy with the direction of this patch. It makes sense that clang would have a tool to help test AST reconstruction from 'external' sources. As you pointed out, it provides a good avenue for clients of the clang AST's to get better test

[PATCH] D21695: [clang] Version support for UBSan handlers

2016-11-29 Thread Vedant Kumar via Phabricator via cfe-commits
vsk accepted this revision. vsk added a reviewer: vsk. vsk added a comment. This revision is now accepted and ready to land. Thanks for working on this. LGTM with a nit. Comment at: lib/CodeGen/CGExpr.cpp:2506 + assert(CheckHandler >= 0 && + CheckHandler <

<    2   3   4   5   6   7