https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 10ee32826fc2acb6bd993c88bdb7142360b6f263 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/10] implement wraps attribute
Signed-off-by: Justin Stitt
-
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 6152bd26438a32711589424f705281291475d548 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
JustinStitt wrote:
Hi, gentle ping.
@efriedma-quic, do you still have concerns with the current implementation (as
an attribute attached to typedefs)? After limiting `wraps` to C and adding
warnings to let users know when the attribute may be stripped, I think it's in
a good spot.
```c
type
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 10ee32826fc2acb6bd993c88bdb7142360b6f263 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/11] implement wraps attribute
Signed-off-by: Justin Stitt
-
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 50e7b1039e514dacc05bb8cd9ff9a3e3df9ed24d Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/11] implement wraps attribute
Signed-off-by: Justin Stitt
-
JustinStitt wrote:
Ping!
I've rebased this PR onto bcd150d2906ac83ea0ab680e981770a71c021a03 and fixed
the issues with the docs not building because of faulty code-blocks.
Bigger picture, for the Linux Kernel, the current plan is to only enable
certain integer sanitizers if support for this wr
@@ -4093,6 +4109,11 @@ Value *ScalarExprEmitter::EmitAdd(const BinOpInfo &op) {
op.RHS->getType()->isPointerTy())
return emitPointerArithmetic(CGF, op, CodeGenFunction::NotSubtraction);
+ if ((op.Ty->isSignedIntegerOrEnumerationType() ||
JustinStitt
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/86618
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 50e7b1039e514dacc05bb8cd9ff9a3e3df9ed24d Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/12] implement wraps attribute
Signed-off-by: Justin Stitt
-
@@ -4077,6 +4077,9 @@ class BinaryOperator : public Expr {
static unsigned sizeOfTrailingObjects(bool HasFPFeatures) {
return HasFPFeatures * sizeof(FPOptionsOverride);
}
+
+ /// Do one of the subexpressions have the wraps attribute?
JustinStitt wrote:
@@ -156,6 +156,10 @@ struct BinOpInfo {
}
return false;
}
+
+ /// Does the BinaryOperator have the wraps attribute?
+ /// If so, we can ellide overflow sanitizer checks.
JustinStitt wrote:
fixed in
[872e5d6](https://github.com/llvm/llvm-project/pu
@@ -2831,6 +2840,9 @@ ScalarExprEmitter::EmitScalarPrePostIncDec(const
UnaryOperator *E, LValue LV,
} else if (type->isIntegerType()) {
QualType promotedType;
bool canPerformLossyDemotionCheck = false;
+BinOpInfo Ops = (createBinOpInfoFromIncDec(
@@ -4093,6 +4109,11 @@ Value *ScalarExprEmitter::EmitAdd(const BinOpInfo &op) {
op.RHS->getType()->isPointerTy())
return emitPointerArithmetic(CGF, op, CodeGenFunction::NotSubtraction);
+ if ((op.Ty->isSignedIntegerOrEnumerationType() ||
JustinStitt
@@ -4455,6 +4455,14 @@ void Sema::AddAlignValueAttr(Decl *D, const
AttributeCommonInfo &CI, Expr *E) {
D->addAttr(::new (Context) AlignValueAttr(Context, CI, E));
}
+static void handleWrapsAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ S.AddWrapsAttr(D, AL);
+}
+
+void S
@@ -4249,6 +4270,10 @@ Value *ScalarExprEmitter::EmitFixedPointBinOp(const
BinOpInfo &op) {
Value *ScalarExprEmitter::EmitSub(const BinOpInfo &op) {
// The LHS is always a pointer if either side is.
if (!op.LHS->getType()->isPointerTy()) {
+if ((op.Ty->isSignedIntegerO
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 50e7b1039e514dacc05bb8cd9ff9a3e3df9ed24d Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/13] implement wraps attribute
Signed-off-by: Justin Stitt
-
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only -triple x86_64-pc-linux-gnu
+// expected-no-diagnostics
+typedef int __attribute__((wraps)) wrapping_int;
+
+void foo(void) {
+ const wrapping_int A = 1;
+ int D = 2147483647 + A;
JustinStitt wrote:
O
JustinStitt wrote:
@efriedma-quic said:
> I'm still not happy with the AST representation here. The current
> representation is likely to cause unpredictable results in edge cases, and
> compatibility constraints mean whatever result the current version happens to
> produce for those cases is
https://github.com/JustinStitt created
https://github.com/llvm/llvm-project/pull/100272
## Summary
Introduce `-fno-sanitize-overflow-idioms` which disables sanitizer
instrumentation for common overflow-dependent code idioms.
## Background
For a wide selection of projects, proper overflow sanit
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/100272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/100272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/100272
>From 06b702cd38943314b2e6f873e64d70baed6f57f7 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 23 Jul 2024 20:21:49 +
Subject: [PATCH 1/3] implement idiom exclusions
Add flag `-fno-sanitize-overf
@@ -312,6 +312,38 @@ This attribute may not be
supported by other compilers, so consider using it together with
``#if defined(__clang__)``.
+Disabling instrumentation of common overflow idioms
+=
+
+There are certain overflow
JustinStitt wrote:
> Actually stuff like unsigned overflows are not UB.
>
> Maybe instead of `-fno-sanitize-overflow-idioms` we convert into
> `unsigned-integer-overflow` into ` check group` so user can
> -fno-sanitize=-unsigned-integer-overflow
Right, unsigned overflow is well-defined. This
JustinStitt wrote:
> I assume you are going to change fronted to avoid compiler abusing these UBs?
Well, like you said, none of this is really undefined behavior and isn't
getting optimized away. The exception being `if ( a + b < a )` which can
definitely have some unexpected results with high
JustinStitt wrote:
> > Right, unsigned overflow is well-defined. This isn't about the semantics of
> > "undefined-ness". We want the unsigned sanitizer ON but some of the things
> > it reports are noisy -- that's what this PR is about
>
> "Idiom" seems to vague to me. kernel has own opinion on
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/100272
>From 06b702cd38943314b2e6f873e64d70baed6f57f7 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 23 Jul 2024 20:21:49 +
Subject: [PATCH 1/4] implement idiom exclusions
Add flag `-fno-sanitize-overf
JustinStitt wrote:
@kees @vitalybuka 3ef8d3c implements `-fsanitize=pattern-exclusion=`.
It supports the following values:
`all` - turn all supported pattern exclusions ON
`none` - turn them all off (has precedence over others, I will add a warning
soon if users try to use this with "all" or an
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/100272
>From 06b702cd38943314b2e6f873e64d70baed6f57f7 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 23 Jul 2024 20:21:49 +
Subject: [PATCH 1/5] implement idiom exclusions
Add flag `-fno-sanitize-overf
JustinStitt wrote:
Hi @efriedma-quic, thanks for dumping all these cases! I will respond to each
one individually.
I understand you think adding a type would be better so I am exploring that
option (I am thinking something similar to [extended
vectors](https://clang.llvm.org/docs/LanguageExte
JustinStitt wrote:
> > > If you declare a variable as both wrapping and non-wrapping, is it
> > > wrapping?
> >
> >
> > I am not sure how to do this. I am sure that with the magic of C anything
> > is possible but I can't conceive a way to have a variable both have the
> > attribute and not
JustinStitt wrote:
@efriedma-quic:
> This is declaring, then defining, a global variable; sorry if that wasn't
> clear.
Gotcha.
> Probably should be an error? It'll be confusing no matter what we do.
I think it's OK for a global variable to be declared then later defined with
additional att
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 50e7b1039e514dacc05bb8cd9ff9a3e3df9ed24d Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/15] implement wraps attribute
Signed-off-by: Justin Stitt
-
JustinStitt wrote:
@efriedma-quic:
> Attributes mostly do modify the type. The few that don't, like "aligned" and
> "may_alias", are a constant source of problems because they get accidentally
> stripped off. (I don't have any personal experience with "noderef".)
So do you believe the current
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 50e7b1039e514dacc05bb8cd9ff9a3e3df9ed24d Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/16] implement wraps attribute
Signed-off-by: Justin Stitt
-
JustinStitt wrote:
In an effort to appease the build bot, I am adding a `-W` flag to turn of
`warn_wraps_attr_var_decl_type_not_integer` which yells at users for trying to
add `__attribute__((wraps))` to things that don't really wrap in the
traditional sense.
https://github.com/llvm/llvm-proj
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 50e7b1039e514dacc05bb8cd9ff9a3e3df9ed24d Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/17] implement wraps attribute
Signed-off-by: Justin Stitt
-
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 50e7b1039e514dacc05bb8cd9ff9a3e3df9ed24d Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH 01/18] implement wraps attribute
Signed-off-by: Justin Stitt
-
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From e73df4dedbb2e2be8b72ca3a8e847d5cbca29bed Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
JustinStitt wrote:
Ping!
Any chance we could land this soon?
I know @efriedma-quic has some different ideas for the implementation of this
feature. However, adding a new type is most likely overkill for what is needed
out of `wraps`. I think the implementation/documentation and testing has la
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 238e3242d12473a072d0d2adc51f18fbeaa927a8 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 1df2f520f6a8ab0e45b80f7a1d680d34f8ab37c9 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
JustinStitt wrote:
FYI: I've rebased and handled merge conflicts (mainly in ReleaseNotes.rst).
This, of course, required a force push.
https://github.com/llvm/llvm-project/pull/86618
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://list
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 1df2f520f6a8ab0e45b80f7a1d680d34f8ab37c9 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/100272
>From 154d3505ab13275086b3dffed67bcdcac52f79a3 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 23 Jul 2024 20:21:49 +
Subject: [PATCH 1/6] implement idiom exclusions
Add flag `-fno-sanitize-overf
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/100272
>From 154d3505ab13275086b3dffed67bcdcac52f79a3 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 23 Jul 2024 20:21:49 +
Subject: [PATCH 1/7] implement idiom exclusions
Add flag `-fno-sanitize-overf
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/100272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/100272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -119,6 +119,10 @@ static SanitizerMask parseArgValues(const Driver &D, const
llvm::opt::Arg *A,
static int parseCoverageFeatures(const Driver &D, const llvm::opt::Arg *A,
bool DiagnoseErrors);
+static int parseOverflowPatternExclusionValues
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 97de8998e2efd2362f9119c3ceea0938347278f4 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
JustinStitt wrote:
@nico
> The test added here was tweaked a bit and then deleted in
> [07a8cba](https://github.com/llvm/llvm-project/commit/07a8cbaf8dc16bebf6e875173d20299d9cc47cc5)
>
> What gives?
>
> Instead of deleting tests, we should revert the PR that adds them and then
> reland the P
@@ -438,6 +438,36 @@ Moved checkers
Sanitizers
--
+- Added the ``-fsanitize-undefined-ignore-overflow-pattern`` flag which can be
+ used to disable specific overflow-dependent code patterns. The supported
+ patterns are: ``add-overflow-test``, ``negated-unsigned-cons
@@ -293,6 +293,48 @@ To silence reports from unsigned integer overflow, you can
set
``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
providing fuzzing signal without blowing up logs.
+Disabling instrumentation for common overflow patterns
+
@@ -293,6 +293,48 @@ To silence reports from unsigned integer overflow, you can
set
``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
providing fuzzing signal without blowing up logs.
+Disabling instrumentation for common overflow patterns
+
@@ -293,6 +293,48 @@ To silence reports from unsigned integer overflow, you can
set
``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
providing fuzzing signal without blowing up logs.
+Disabling instrumentation for common overflow patterns
+
@@ -438,6 +438,36 @@ Moved checkers
Sanitizers
--
+- Added the ``-fsanitize-undefined-ignore-overflow-pattern`` flag which can be
+ used to disable specific overflow-dependent code patterns. The supported
+ patterns are: ``add-overflow-test``, ``negated-unsigned-cons
@@ -293,6 +293,48 @@ To silence reports from unsigned integer overflow, you can
set
``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
providing fuzzing signal without blowing up logs.
+Disabling instrumentation for common overflow patterns
+
@@ -293,6 +293,48 @@ To silence reports from unsigned integer overflow, you can
set
``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
providing fuzzing signal without blowing up logs.
+Disabling instrumentation for common overflow patterns
+
@@ -293,6 +293,48 @@ To silence reports from unsigned integer overflow, you can
set
``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
providing fuzzing signal without blowing up logs.
+Disabling instrumentation for common overflow patterns
+
@@ -0,0 +1,63 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu
-fsanitize=signed-integer-overflow,unsigned-integer-overflow
-fsanitize-undefined-ignore-overflow-pattern=all %s -emit-llvm -o - | FileCheck
%s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu
-fsanitize
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/104889
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -293,6 +293,48 @@ To silence reports from unsigned integer overflow, you can
set
``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
providing fuzzing signal without blowing up logs.
+Disabling instrumentation for common overflow patterns
+
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/105709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JustinStitt created
https://github.com/llvm/llvm-project/pull/105709
>From @vitalybuka's review on https://github.com/llvm/llvm-project/pull/104889:
- [x] remove unused variable in tests
- [x] rename `post-decr-while` --> `unsigned-post-decr-while`
- [x] split `add-overflow-te
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/105709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JustinStitt wrote:
> Regarding there not being a `no-wraps` attribute. What happens with code like
> this? Is the attribute lost / casted away during the addition?
>
> ```
> wrapping_int a = INT_MAX;
> a = (int) a + 1;
> ```
Good question, the attribute is cast away (intentionally so). Additio
JustinStitt wrote:
> Iām a little concerned about not allowing the attribute in C++ - the
> existence of other options in C++ does not mean they are an option (due to
> various and sundry restrictions of C++ version upgrades different projects
> have), but also you trivially end up in cases wh
@@ -4806,6 +4806,34 @@ getOverflowPatternBinOp(const BinaryOperator *E) {
return {};
}
+/// Compute and set the OverflowPatternExclusion bit based on whether the
JustinStitt wrote:
I wanted to avoid calling `getOverflowPatternBinOp()` as it is more expensiv
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/105709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From af16c497b1323983d55f92d6cfb9ab2c99a21639 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 58df542edf7d1a9f65fc804f23a2b209a49f5c5f Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/86618
>From 6fb8f6841795c44471a326a9d096a226cea9f4a8 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 5 Mar 2024 03:14:49 +
Subject: [PATCH] implement wraps attribute
Signed-off-by: Justin Stitt
---
cl
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
JustinStitt wrote:
@vitalybuka Can we move forward with this? The most recent commit uses the
`=sanitize` `=no_sanitize` wording that you preferred.
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
JustinStitt wrote:
Hi Vitaly, thanks for expanding the usefulness of type suppression through
SCLs. LGTM
https://github.com/llvm/llvm-project/pull/114754
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
JustinStitt wrote:
@vitalybuka any idea how lldb-server is failing with `UNRESOLVED`? How in the
world are any of the changes here affecting lldb-server?
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.l
https://github.com/JustinStitt created
https://github.com/llvm/llvm-project/pull/115094
> [!NOTE]
> Expansion of https://github.com/llvm/llvm-project/pull/86618, with a larger
> scope including `no_wraps` and
> [SSCL](https://clang.llvm.org/docs/SanitizerSpecialCaseList.html)
> integration.
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/107332
>From 548efc6414503f8ae005f1bd9ef2c7f15ad16241 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 3 Sep 2024 18:28:53 -0700
Subject: [PATCH 1/6] hook up sscl categories with overflow/truncation
sanitize
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
JustinStitt wrote:
BTW doc build failures linked to here:
https://github.com/llvm/llvm-project/pull/109220
unrelated to my changes š
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
JustinStitt wrote:
@melver
> Oh nice. If you have that almost done, why do you still want the filterlist?
> For the Linux kernel usecase, wouldn't the attribute be preferrable? My
> intuition tells me that maintaining a filterlist detached from the code will
> cause headaches, esp. during ref
JustinStitt wrote:
@vitalybuka
> Is "Test documentation build" error related?
I am noticing this documentation build failing in other [un-related Clang
patchsets](https://github.com/llvm/llvm-project/actions/runs/11598884769/job/32295763452?pr=114281)
(related to `ClangFormattedStatus`?). I d
@@ -0,0 +1,105 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+// Verify ubsan doesn't emit checks for ignorelisted types
+// RUN: %clang_cc1 -triple x86_64-linux-gnu
-fsanitize=signed-integer-overflow,unsigned-integer-overflow
-fsanitize-ignorelist=%t/int.ignorelist -emit-ll
@@ -15,8 +15,9 @@ file at compile-time.
Goal and usage
==
-Users of sanitizer tools, such as :doc:`AddressSanitizer`,
:doc:`ThreadSanitizer`
-or :doc:`MemorySanitizer` may want to disable or alter some checks for
+Users of sanitizer tools, such as :doc:`AddressSan
@@ -1,23 +0,0 @@
-// Verify ubsan vptr does not check down-casts on ignorelisted types.
-// RUN: echo "type:_ZTI3Foo" > %t-type.ignorelist
-// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsanitize=vptr
-fsanitize-recover=vptr -emit-llvm %s -o - | FileCheck %s --check-prefix=DEFAULT
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
JustinStitt wrote:
> I wished that we could just attach attributes to type, e.g. `typedef int
> __attribute__((no_sanitize("signed-integer-overflow")) wrapping_int` or
> something. One thing here is that this should _not_ be a type modifier (like
> volatile and such), so it does not change the
@@ -197,6 +197,18 @@ static bool CanElideOverflowCheck(const ASTContext &Ctx,
const BinOpInfo &Op) {
if (!Op.mayHaveIntegerOverflow())
return true;
+ if (Op.Ty->isSignedIntegerType() &&
JustinStitt wrote:
I'll add a comment, good idea :)
https://gith
https://github.com/JustinStitt edited
https://github.com/llvm/llvm-project/pull/107332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
https://github.com/JustinStitt updated
https://github.com/llvm/llvm-project/pull/107332
>From 548efc6414503f8ae005f1bd9ef2c7f15ad16241 Mon Sep 17 00:00:00 2001
From: Justin Stitt
Date: Tue, 3 Sep 2024 18:28:53 -0700
Subject: [PATCH 01/13] hook up sscl categories with overflow/truncation
saniti
@@ -48,6 +48,64 @@ Example
$ clang -fsanitize=address -fsanitize-ignorelist=ignorelist.txt foo.c ;
./a.out
# No error report here.
+Usage with UndefinedBehaviorSanitizer
+=
+
+The arithmetic overflow sanitizers ``unsigned-integer-overfl
@@ -831,6 +831,28 @@ ASTContext::getCanonicalTemplateTemplateParmDecl(
return CanonTTP;
}
+/// Check if a type can have its sanitizer instrumentation elided.
+/// Determine this by its presence in a SCL alongside its specified categories.
+/// For example:
+/// ignorelist.tx
101 - 200 of 275 matches
Mail list logo
