[PATCH] D12761: MPI-Checker patch for Clang Static Analyzer

Alexander Droste via cfe-commits cfe-commits at lists.llvm.org
Sat Sep 12 03:51:33 PDT 2015


Alexander_Droste added inline comments.

================
Comment at: tools/clang/lib/StaticAnalyzer/Checkers/Checkers.td:524
@@ +523,3 @@
+def MPIChecker : Checker<"MPI-Checker">,
+  HelpText<"Checks MPI code written in C">,
+  DescFile<"MPIChecker.cpp">;
----------------
gribozavr wrote:
> Does it only works with C code, or does it work with C++ code that uses C bindings for MPI?  I think it is safe to describe it as "Checks MPI code".
I guess you're right, it should work with C++ code that uses C bindings for MPI
but I've only evaluated and tested the checker on plain C code.
Should we delay that decision to the end of the review?


================
Comment at: tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPICheckerAST.cpp:22
@@ +21,3 @@
+
+void MPICheckerAST::initMPITypeContainer() {
+  mpiTypes_ = {"MPI_BYTE",
----------------
gribozavr wrote:
> MPICH has its header files annotated for Clang for a few years already, I think we should be using the annotations instead of textually matching the constants.  Moreover, some users are using those annotations for their own datatypes.
I agree that using annotations is preferable, as the type matching is checked
during normal compilation but as you mentioned,
it necessary that those are implemented in a specific MPI implementation.
The check would support type matching for any implementation.

Custom buffer types and custom MPI types are simply skipped why that should not
impose a problem. Further, I planned to support custom types in the future. They could get 
passed as something like a list of pairs to the checker 
{{"customBufType", "customMPI"},...}.

================
Comment at: tools/clang/lib/StaticAnalyzer/Checkers/MPI-Checker/MPICheckerAST.hpp:101
@@ +100,3 @@
+  MPIFunctionClassifier funcClassifier_;
+  llvm::SmallVector<std::string, 32> mpiTypes_;
+  MPIBugReporter bugReporter_;
----------------
gribozavr wrote:
> This should be a hashtable-based set, like `llvm::DenseSet`.  Scanning this vector over and over again is wasteful.
`llvm::DenseSet<std::string>` does not compile. 
`error: no member named 'getEmptyKey'  ..`
Is there an alternative?


http://reviews.llvm.org/D12761





More information about the cfe-commits mailing list