This revision was automatically updated to reflect the committed changes.
Closed by commit rL296214: [ubsan] Detect signed overflow UB in remainder
operations (authored by vedantk).
Changed prior to commit:
https://reviews.llvm.org/D29437?vs=89734&id=89753#toc
Repository:
rL LLVM
https://re
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.
LGTM.
https://reviews.llvm.org/D29437
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/
vsk updated this revision to Diff 89734.
vsk added a comment.
- Add a small test that shows why the 'isIntegerType' check is required (we'd
crash otherwise).
https://reviews.llvm.org/D29437
Files:
lib/CodeGen/CGExprScalar.cpp
test/CodeGen/ubsan-promoted-arith.cpp
Index: test/CodeGen/ubsa
efriedma added inline comments.
Comment at: lib/CodeGen/CGExprScalar.cpp:2380
+ CGF.SanOpts.has(SanitizerKind::SignedIntegerOverflow)) &&
+ Ops.Ty->isIntegerType()) {
CodeGenFunction::SanitizerScope SanScope(&CGF);
I don't think you need the isInt
vsk added a comment.
In https://reviews.llvm.org/D29437#664379, @regehr wrote:
> Does this check need to be sensitive to the dialect of C/C++ that the user
> asked for? I know that it used to be the case that the standard could be read
> either way for this case, but as you observe it is now un
regehr added a comment.
Does this check need to be sensitive to the dialect of C/C++ that the user
asked for? I know that it used to be the case that the standard could be read
either way for this case, but as you observe it is now unambiguously UB.
https://reviews.llvm.org/D29437
_
vsk created this revision.
Teach ubsan to diagnose remainder operations which have undefined behavior due
to signed overflow.
My copy of the C11 spec draft (6.5.5.6) says that: if the quotient a/b is
representable, (a/b)*b + a%b shall equal a; otherwise, the behavior of both a/b
and a%b is und
