date:20240805

[clang] [llvm] [Sanitizer] Make sanitizer passes idempotent (PR #99439)

2024-08-05 Thread via cfe-commits


https://github.com/skc7 updated https://github.com/llvm/llvm-project/pull/99439

>From 3c7c677b7d6dc3934fddc452021dcc2c06086606 Mon Sep 17 00:00:00 2001
From: skc7 
Date: Thu, 18 Jul 2024 11:49:24 +0530
Subject: [PATCH] [Sanitizer] Make sanitizer passes idempotent.

---
 clang/test/CodeGenObjC/no-sanitize.m  |  2 +-
 .../include/llvm/Transforms/Instrumentation.h |  4 ++
 .../Instrumentation/AddressSanitizer.cpp  |  5 ++
 .../Instrumentation/DataFlowSanitizer.cpp |  3 +
 .../Instrumentation/HWAddressSanitizer.cpp|  4 ++
 .../Instrumentation/Instrumentation.cpp   | 35 
 .../Instrumentation/MemorySanitizer.cpp   |  4 ++
 .../Instrumentation/ThreadSanitizer.cpp   |  3 +
 .../AddressSanitizer/asan-pass-second-run.ll  | 55 +++
 .../AddressSanitizer/missing_dbg.ll   |  2 +-
 .../dfsan-pass-second-run.ll  | 17 ++
 .../hwasan-pass-second-run.ll | 41 ++
 .../MemorySanitizer/msan-pass-second-run.ll   | 43 +++
 .../ThreadSanitizer/tsan-pass-second-run.ll   | 28 ++
 14 files changed, 244 insertions(+), 2 deletions(-)
 create mode 100644 
llvm/test/Instrumentation/AddressSanitizer/asan-pass-second-run.ll
 create mode 100644 
llvm/test/Instrumentation/DataFlowSanitizer/dfsan-pass-second-run.ll
 create mode 100644 
llvm/test/Instrumentation/HWAddressSanitizer/hwasan-pass-second-run.ll
 create mode 100644 
llvm/test/Instrumentation/MemorySanitizer/msan-pass-second-run.ll
 create mode 100644 
llvm/test/Instrumentation/ThreadSanitizer/tsan-pass-second-run.ll

diff --git a/clang/test/CodeGenObjC/no-sanitize.m 
b/clang/test/CodeGenObjC/no-sanitize.m
index abaf6fab26ab6..b5c6a5ad745f3 100644
--- a/clang/test/CodeGenObjC/no-sanitize.m
+++ b/clang/test/CodeGenObjC/no-sanitize.m
@@ -2,7 +2,7 @@
 
 @interface I0 @end
 @implementation I0
-// CHECK-NOT: sanitize_address
+// CHECK-NOT: Function Attrs: sanitize_address
 - (void) im0: (int) a0 __attribute__((no_sanitize("address"))) {
   int (^blockName)(void) = ^int(void) { return 0; };
 }
diff --git a/llvm/include/llvm/Transforms/Instrumentation.h 
b/llvm/include/llvm/Transforms/Instrumentation.h
index 969c2cd12f3f0..885d3249fb4f8 100644
--- a/llvm/include/llvm/Transforms/Instrumentation.h
+++ b/llvm/include/llvm/Transforms/Instrumentation.h
@@ -30,6 +30,10 @@ class Triple;
 class OptimizationRemarkEmitter;
 class Comdat;
 class CallBase;
+class Module;
+
+/// Check if module has flag attached, if not add the flag.
+bool checkIfAlreadyInstrumented(Module &M, StringRef Flag);
 
 /// Instrumentation passes often insert conditional checks into entry blocks.
 /// Call this function before splitting the entry block to move instructions
diff --git a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp 
b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
index 9fb1df7ab2b79..9416c8d87dd9d 100644
--- a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -1251,6 +1251,11 @@ AddressSanitizerPass::AddressSanitizerPass(
 
 PreservedAnalyses AddressSanitizerPass::run(Module &M,
 ModuleAnalysisManager &MAM) {
+  // Return early if nosanitize_address module flag is present for the module.
+  // This implies that asan pass has already run before.
+  if (checkIfAlreadyInstrumented(M, "nosanitize_address"))
+return PreservedAnalyses::all();
+
   ModuleAddressSanitizer ModuleSanitizer(
   M, Options.InsertVersionCheck, Options.CompileKernel, Options.Recover,
   UseGlobalGC, UseOdrIndicator, DestructorKind, ConstructorKind);
diff --git a/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp 
b/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
index 113d39b4f2af7..b4b5f67d2e62d 100644
--- a/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
@@ -3473,6 +3473,9 @@ void DFSanVisitor::visitPHINode(PHINode &PN) {
 
 PreservedAnalyses DataFlowSanitizerPass::run(Module &M,
  ModuleAnalysisManager &AM) {
+  // Return early if nosanitize_dataflow module flag is present for the module.
+  if (checkIfAlreadyInstrumented(M, "nosanitize_dataflow"))
+return PreservedAnalyses::all();
   auto GetTLI = [&](Function &F) -> TargetLibraryInfo & {
 auto &FAM =
 AM.getResult(M).getManager();
diff --git a/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp 
b/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
index 812874ff3c173..95433a216b168 100644
--- a/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -57,6 +57,7 @@
 #include "llvm/Support/RandomNumberGenerator.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/TargetParser/Triple.h"
+#include "llvm/Transforms/Instrumentation.h"
 #include "llvm/Transforms/Instrumenta

[clang] [Clang][Sema][OpenMP] Allow `num_teams` to accept multiple expressions (PR #99732)

2024-08-05 Thread Johannes Doerfert via cfe-commits



@@ -11357,8 +11358,13 @@ void 
OMPClauseReader::VisitOMPAllocateClause(OMPAllocateClause *C) {
 
 void OMPClauseReader::VisitOMPNumTeamsClause(OMPNumTeamsClause *C) {
   VisitOMPClauseWithPreInit(C);
-  C->setNumTeams(Record.readSubExpr());
   C->setLParenLoc(Record.readSourceLocation());
+  unsigned NumVars = C->varlist_size();
+  SmallVector Vars;
+  Vars.reserve(NumVars);
+  for ([[maybe_unused]] unsigned I : llvm::seq(NumVars))

jdoerfert wrote:

Looks to me like it works fine in C++:
https://cxx.godbolt.org/z/7W5zxs1ME

https://github.com/llvm/llvm-project/pull/99732
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] target ABI: improve call parameters extensions handling (PR #100757)

2024-08-05 Thread Jonas Paulsson via cfe-commits

@@ -1185,6 +1189,9 @@ Currently, only the following parameter attributes are 
defined:
 value should be sign-extended to the extent required by the target's
 ABI (which is usually 32-bits) by the caller (for a parameter) or
 the callee (for a return value).
+``noext`` This indicates to the code generator that the parameter or return
+value has the high bits undefined, as for a struct in register, and
+therefore does not need to be sign or zero extended.

JonPsson1 wrote:

> Can we do IR verifier for ABI illegal cases instead?

In previous discussions it has been agreed to generally let the target decide 
on how to act on the argument extensions attributes. So we decided to keep the 
check for these in the (SystemZ) backend. Per my understanding, this is related 
to the target platform ABI - some targets like SystemZ has specific extension 
requirements of arguments. Others do not and can therefore ignore these 
attributes. Therefore, having a general IR verifier for this doesn't quite make 
sense - unless one would add a new hook as well to check with the target that 
it depends on valid argument extension attributes.

> My suggestion is to introduce ABI verification code for each target in the IR 
> verifier...

I agree this would make sense, but think this could be a follow-up patch once 
we have the needed parts this patch provides.

> The goal is to get some sort of error from code like that, instead of an 
> obscure miscompile.

Yes, if the front-end or an instrumentation pass forgets to add the extension, 
it could lead to wrong-code that is hard to track down. This is especially 
treacherous since somebody might work on a target that do not care about this 
at all and introduce a problem on another target that depends on it. In such a 
case it would be great if e.g. the SystemZ buildbot would fail by detecting the 
case with no extension attribute.

https://github.com/llvm/llvm-project/pull/100757
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-tidy] Fix smart pointers handling in bugprone-use-after-move (PR #94869)

2024-08-05 Thread via cfe-commits


https://github.com/martinboehme requested changes to this pull request.

Sorry - I only noticed now after your rebase that this had been sitting in my 
review queue  for quite a while.

*  I would suggest rewording the option name. The "ignore" 
(`IgnoreNonDerefSmartPtrs`) reads like a negation, which makes it harder to 
reason about what the option does. How about `AllowMovedSmartPtrUse`? (I think 
maybe the "non-deref" can be omitted from the option name -- I think it's 
sufficient that it's explained in the documentation).

*  In https://github.com/llvm/llvm-project/issues/90174, I suggested that if we 
wanted to change the default behavior, we should survey users to see what their 
opinions / preferences are. Have you done this? If not, I think the default 
behavior (when the option is not set) should remain unchanged.

https://github.com/llvm/llvm-project/pull/94869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [X86][AVX10.2] Support AVX10.2 VNNI FP16/INT8/INT16 new instructions (PR #101783)

2024-08-05 Thread Shengchen Kan via cfe-commits


https://github.com/KanRobert approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/101783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Handle CXXInheritedCtorInitExpr in ResultObjectVisitor. (PR #99616)

2024-08-05 Thread via cfe-commits

martinboehme wrote:

@haoNoQ Thank you for going to the trouble to explain all of this in detail!

> I'm very open to changes in `ConstructionContext` to accommodate your needs,
> like provide extra information that we didn't need but you did, or provide it
> in a different way.

I haven't looked in detail yet, but I think all of the information we need is
there.

The main thing I'm wondering is whether we can make it so there are fewer case
distinctions that the code in `FlowSensitive` would need to perform -- i.e. so
that we wouldn't need to handle all of the possible cases in
`ConstructionContext::Kind` individually.

As far as I can tell, the various "intermediate" classes in the class hierarchy
look as if they provide a mechanism for this. I.e. instead of distinguishing
between all of the possible leaf classes, we would merely handle
`VariableConstructionContext`, `ConstructorInitializerConstructionContext`,
`TemporaryObjectConstructionContext`, and `ReturnedValueConstructionContext`. I
_think_ that for our purposes (i.e. identifying the result object that a record
prvalue initializes), these intermediate classes should provide all of the
information we need. (I believe the finer-grained information is only necessary
for the additional analysis that you do, e.g. for temporary destructors, as you
explain.) Does this sound right?

If you agree that this works, then the main question to me is how we make sure
that we make sure we update our code if more cases are added to
`ConstructionContext`. This is easy to do with a switch-case over
`ConstructionContext::Kind`, as the compiler will warn if any of the cases are
not handled, but we don't get any such warning when doing a series of
`dyn_cast`s over the various "intermediate" classes in the hierarchy (i.e.
`VariableConstructionContext` and so on). We could, of course, still use a
switch case but then cast to the appropriate intermediate class. I see that you
also do in this in some places in the code, e.g. in
[ExprEngineCXX.cpp](https://github.com/llvm/llvm-project/blob/86f7374078288e2b3d3d0fd66428f7752e2319e6/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp#L132).
Is this the approach that you would recommend?

https://github.com/llvm/llvm-project/pull/99616
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

1 2 3 4 >

1 - 100 of 378 matches

Mail list logo