[PATCH] D50594: [analyzer] [NFC] Introduce separate targets for testing the analyzer: check-clang-analyzer and check-clang-analyzer-z3

mikhail.ramalho added a comment. I can't comment on the code but it works correctly for me. I wish I had it a couple of months ago :) https://reviews.llvm.org/D50594 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-

[PATCH] D45920: [analyzer] Move RangeSet related declarations into the RangedConstraintManager header.

mikhail.ramalho commandeered this revision. mikhail.ramalho added a reviewer: rnkovacs. mikhail.ramalho added a comment. Commandeering the PR because of GSoC. Repository: rC Clang https://reviews.llvm.org/D45920 ___ cfe-commits mailing list cfe-c

[PATCH] D45517: [analyzer] WIP: False positive refutation with Z3

mikhail.ramalho added a comment. Commandeering the PR because of GSoC. https://reviews.llvm.org/D45517 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a comment. > Could you provide a minimal example where USRs are not generated? It might > be the case that there are other ways to fix it. Sure, I'll try to reduce our testcase, but basically we have an ASTFrontendAction [0] that adds a set of intrinsics [1] to the preproce

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho updated this revision to Diff 148828. mikhail.ramalho retitled this revision from "[analyzer] WIP: False positive refutation with Z3" to "[analyzer] False positive refutation with Z3". mikhail.ramalho added a comment. Added test cases and updated the analyzer-config tests with the

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho updated this revision to Diff 148969. mikhail.ramalho marked 6 inline comments as done. mikhail.ramalho added a comment. 1. Moved FalsePositiveRefutationBRVisitor::Profile definition to BugReporterVisitor.cpp 2. Update test cases two run twice, with and without the crosscheck 3. R

[PATCH] D49749: [analyzer] Admit that we can't simplify the newly produced mixed Loc/NonLoc expressions.

mikhail.ramalho added a comment. It fixes Xerces verification. Thanks. Repository: rC Clang https://reviews.llvm.org/D49749 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49536: [Analyzer] Quick Fix for exponential execution time when simpilifying complex additive expressions

mikhail.ramalho added a comment. I getting the following error when analyzing `test/Analysis/plist-macros.cpp`, usign z3 as constraint manager (`-analyzer-constraints=z3 -DANALYZER_CM_Z3`): /home/mgadelha/llvm/tools/clang/test/Analysis/plist-macros.cpp:640:16: error: CHECK-NEXT: expected stri

[PATCH] D49536: [Analyzer] Quick Fix for exponential execution time when simpilifying complex additive expressions

mikhail.ramalho added a comment. > Uhm, dunno, plist/FileCheck tests are annoying. What i usually do to make > sense out of them is update the tested output with the actual output and look > at git diff. From that it's usually obvious what exactly happened (warnings > added, warnings removed, w

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho created this revision. mikhail.ramalho added reviewers: arphaman, rsmith. Herald added a subscriber: cfe-commits. Small change on how the USRGen code prints the location. The patch fixes an issue when there are #line directives or linemarkes in the file, e.g.: #line 3 int Fu

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a comment. ping. Repository: rC Clang https://reviews.llvm.org/D42966 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho updated this revision to Diff 149317. mikhail.ramalho marked 6 inline comments as not done. mikhail.ramalho added a comment. - Simplified refutation process: it now collects all the constraints in a given path and, only when it reaches the root node, the refutation manager is crea

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho added subscribers: dcoughlin, george.karpenkov, NoQ. mikhail.ramalho added a comment. Hi, > Just a bit of context and to have some expectation management regarding > this patch. The main purpose of this implementation was to back a thesis. > It was made under a very serious time

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho added inline comments. Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2391 +if (!RefutationMgr->isModelFeasible()) + BR.markInvalid("Infeasible constraints", N->getLocationContext()); + } george.karpenkov wrote: > That would

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho added inline comments. Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h:183 + virtual void reset() {} + virtual bool isModelFeasible() { return true; } + virtual void addRangeConstraints(ConstraintRangeTy) {} geo

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho added inline comments. Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h:183 + virtual void reset() {} + virtual bool isModelFeasible() { return true; } + virtual void addRangeConstraints(ConstraintRangeTy) {} geo

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho updated this revision to Diff 149524. mikhail.ramalho added a comment. - Simplified the API even further by constructing a Z3ConstraintManager object directly. - Update isModelFeasible to return a isModelFeasible - Update code with the fix for 1-bit long integer https://reviews.

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho updated this revision to Diff 149653. mikhail.ramalho added a comment. Update patch based on https://reviews.llvm.org/D47640 and https://reviews.llvm.org/D47689. I updated the test case as the cross check is not marking the true bug as invalid anymore. My `make clang-test` is s

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho added inline comments. Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2366 + + SMTConstraintManager *SMTRefutationMgr = + static_cast(RefutationMgr.get()); I'm not happy about this cast. Suggestions are welcome. https://review

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho added a subscriber: rnkovacs. mikhail.ramalho added a comment. > Awesome! Does it mean that the optimization for adding less constraints > was in fact buggy? I pretty sure it was not related to the optimizations, I removed them days ago (in the previous version of this patch) and

[PATCH] D45517: [analyzer] False positive refutation with Z3

mikhail.ramalho updated this revision to Diff 149664. mikhail.ramalho edited the summary of this revision. mikhail.ramalho added a comment. Fix naming issue. https://reviews.llvm.org/D45517 Files: include/clang/StaticAnalyzer/Core/AnalyzerOptions.h include/clang/StaticAnalyzer/Core/BugRepor

[PATCH] D54391: Fix compatibility with z3-4.8.1

mikhail.ramalho added a comment. Since we're supporting version 4.8.1 now, the cmake file should be changed to "minimum" instead of "exact". Repository: rL LLVM https://reviews.llvm.org/D54391 ___ cfe-commits mailing list cfe-commits@lists.llvm.

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho updated this revision to Diff 190893. mikhail.ramalho added a comment. Update Z3 script to use cmake's `try_run` in order to retrieve the version from the lib. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978 Files: clang/CMake

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. Hi all, Sorry for the massive delay, but I just updated the `FindZ3` script to retrieve the version from the lib. I changed it to use `try_run` instead of `try_compile` so we can get the version number. I tried to use @brzycki code to get the version from the h

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. In D54978#1431786 , @ddcc wrote: > In D54978#1431430 , @mikhail.ramalho > wrote: > > > Sorry for the massive delay, but I just updated the `FindZ3` script to > > retrieve the versi

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. In D54978#1431788 , @ddcc wrote: > The only relevant commit that I can find is > https://github.com/Z3Prover/z3/commit/2cb4223979cc94e2ebc4e49a9e83adbdcd2b6979 > , but it first landed in z3 4.6.0. It looks like it's speci

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho updated this revision to Diff 191095. mikhail.ramalho added a comment. Fixes: - `FindZ3.cmake` format . - Wrong `SMTExpr` namespace in `SMTConstraintManager.h`. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978 Files: clang/CMak

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho updated this revision to Diff 191152. mikhail.ramalho added a comment. Updated script to parse Z3's headers and changed the workflow to handle cross compilation cases. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978 Files: cla

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. Hi all, I just updated the CMake script to get the version by parsing the header, however, I just found a potential issue in the previous approach: if we have incompatible libs in the path (32-bits libs when compiling in 64-bit mode) the CMake config will succe

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho updated this revision to Diff 191305. mikhail.ramalho added a comment. Fix copy-and-paste error. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978 Files: clang/CMakeLists.txt clang/cmake/modules/FindZ3.cmake clang/include/cla

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho marked an inline comment as done. mikhail.ramalho added a comment. Fixed. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. > ! In D54978#1440464 , @ddcc wrote: > > Do you know if this configuration builds fine now? It's working fine now, I'll push it later today. > ! In D54978#1441355 , @gou4shi1 > wr

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. In D54978#1441453 , @gou4shi1 wrote: > > ! In D54978#1441417 , > > @mikhail.ramalho wrote: > > Sure, I'll create a new revision with the added functions tonight. > > I am very happ

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. In D54978#1442493 , @aprantl wrote: > I'm afraid this broke some bots that build with `LLVM_ENABLE_MODULES=1`. > > For example: > > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/22411/consoleFull#710926295dd1929e

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. In D54978#1447107 , @gou4shi1 wrote: > My own out-of-tree pass `#include ` and use cmake's > `add_llvm_library` to compile it into a `.so` > However, `opt -load-pass-plugin=my-pass.so -passes="foo" bar.ll` fails: > `opt:

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. Hi everyone, I just saw your messages and reverted the commits. Sorry for the inconvenience, but for some reason I didn't get any email from the bots. Could you send me the link with the failure? @brzycki, I'm using Ubuntu 18.04.2 and I'll try to reproduce the e

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho reopened this revision. mikhail.ramalho added a comment. This revision is now accepted and ready to land. Reopening the revision as it was reverted. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978 __

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. @brzycki, I can't reproduce your error. Maybe you're missing `-DLLVM_ENABLE_Z3_SOLVER=OFF`? $ cmake -GNinja ../llvm -DLLVM_ENABLE_PROJECTS=clang -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/home/mgadelha/myclang -DCMAKE_LINKER=/usr/bin/ld.gold -DLLVM_ENABLE

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. I found a `CHECK_CXX_SOURCE_COMPILES`, which seems to be used in a number of places in LLVM. I'll give it a try. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. Looks like my last email got lost: I'm wondering if we can remove the binary requirement all together: is it possible to run a small program that would return EXIT_SUCCESS if the library is the correct version? Something like: #include int main() {

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. In D54978#1395561 , @brzycki wrote: > In D54978#1395476 , @mikhail.ramalho > wrote: > > > I'm wondering if we can remove the binary requirement all together: is it > > possible to

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho updated this revision to Diff 186757. mikhail.ramalho added a comment. Update FindZ3.cmake to do a runtime check of the version. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54978/new/ https://reviews.llvm.org/D54978 Files: clang/CMakeLists.txt clang/cmake/modules/

[PATCH] D54978: Move the SMT API to LLVM

mikhail.ramalho added a comment. Hi guys, I just sent the first prototype of the solution. All the magic happens inside the `CHECK_CXX_SOURCE_RUNS` call. There is still one thing to do: currently, the program is hard-coded to check for version 4.7.1. We should either get it from the `find_pack

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho marked an inline comment as done. mikhail.ramalho added a comment. ping https://reviews.llvm.org/D36610 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho updated this revision to Diff 142578. mikhail.ramalho added a comment. Rebased to current master. Removed the getFullyQualifiedName overloaded function. https://reviews.llvm.org/D36610 Files: include/clang/AST/QualTypeNames.h lib/AST/QualTypeNames.cpp unittests/Tooling/Qu

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho updated this revision to Diff 142709. mikhail.ramalho added a comment. Renamed variables in the test so it doesn't match the type name https://reviews.llvm.org/D36610 Files: include/clang/AST/QualTypeNames.h lib/AST/QualTypeNames.cpp unittests/Tooling/QualTypeNamesTest.cpp

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a comment. Sure. Basically, the previous code would not generate the USR for the function's parameters. The issue was that SM.getFileEntryForID would return NULL because there is no actual file, that's why I changed to get the presumedLoc and build the name using the colu

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a comment. ping. Repository: rC Clang https://reviews.llvm.org/D42966 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho marked an inline comment as done. mikhail.ramalho added a comment. ping. Comment at: unittests/Tooling/QualTypeNamesTest.cpp:225 + + TypeNameVisitor PrintingPolicy; + PrintingPolicy.ExpectedQualTypeNames["a"] = "short"; rnk wrote: > Please cho

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a subscriber: arphaman. mikhail.ramalho added a comment. > Why wasn't there a file for function parameter? Function parameters *are* > declared in some file, or am I missing something? They are declared in some file defined by the line markers; the file are not registered i

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a subscriber: rsmith. mikhail.ramalho added a comment. Hi, > Or is the that whenever there's a `#line` directive we get into a > "virtual" file that's not registered in the `SourceManager`? The virtual file is actually registered in the SourceManager but the FileEntry for

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho marked an inline comment as done. mikhail.ramalho added a comment. Ping. https://reviews.llvm.org/D36610 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a comment. Hi, > After thinking about this a bit, and use cases like rename and > find-declaration that could be USR based, I think including some location > information is the right way to go, which I think is the current behavior. What do you man by location information

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho added subscribers: rsmith, rnk. mikhail.ramalho added a comment. Last review asked to change the test case, I just want to make sure everything is fine this time. https://reviews.llvm.org/D36610 ___ cfe-commits mailing list cfe-commi

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a comment. Hi, > Filename + offset for things like function parameters, where we have to > identify the particular function declaration they're part of. > For static functions themselveds, just the filename. I think this is > current behavior in both cases. But then we'r

[PATCH] D42966: Fix USR generation in the presence of #line directives or linemarkes

mikhail.ramalho added a comment. Hi, > I would say "yes". Let's not rely on linemarkers, unless we can explain > why that's a good idea. Sounds reasonable to me, specially considering cases like rename and find-declaration. > Where do virtual files come from in the first place? From the linem

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho added a comment. Thanks. I just need someone to push it, as I don't have write access to the repo. https://reviews.llvm.org/D36610 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinf

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho updated this revision to Diff 145255. mikhail.ramalho added a comment. Fixed the test case. https://reviews.llvm.org/D36610 Files: include/clang/AST/QualTypeNames.h lib/AST/QualTypeNames.cpp unittests/Tooling/QualTypeNamesTest.cpp Index: unittests/Tooling/QualTypeNamesTe

[PATCH] D48561: [Analyzer] Moved RangeConstraintManager to header. NFC.

mikhail.ramalho added a comment. In https://reviews.llvm.org/D48561#1146114, @george.karpenkov wrote: > After thinking about this change a bit longer, I think it does not make sense. > > Albeit poorly named, the previous design had a purpose: > `RangedConstraintManager` is a public interface, an

[PATCH] D48561: [Analyzer] Moved RangeConstraintManager to header. NFC.

mikhail.ramalho abandoned this revision. mikhail.ramalho added a comment. We won't need this patch anymore because we'll try another approach in https://reviews.llvm.org/D48565. Repository: rC Clang https://reviews.llvm.org/D48561 ___ cfe-commit

[PATCH] D78457: [analyzer][Z3-refutation] Fix a refutation BugReporterVisitor bug

mikhail.ramalho added a comment. Nice work, @steakhal! I remember discussing with @NoQ a way of going backward on the bug report, from the error node, and never add constraints of symbols that were already collected; that way we would always have the tighter constraints. I don't quite remember

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho created this revision. Herald added a subscriber: klimek. In our user case, we need to generate unique names for every tag, including anonymous structs/unions. This adds a custom PrintingPolicy option to getFullyQualifiedName and the test case shows that different names are gene

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho added a comment. Should I update the other tests in QualTypeNamesTest.cpp to use multiline strings as well? https://reviews.llvm.org/D36610 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailma

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho updated this revision to Diff 63. mikhail.ramalho added a comment. Updated QualTypeNamesTest.cpp to use multiline string in all tests. Also ran clang-format -style=LLVM for code style. https://reviews.llvm.org/D36610 Files: include/clang/Tooling/Core/QualTypeNames.h lib

[PATCH] D86223: [analyzer][z3] Use more elaborate z3 variable names in debug build

mikhail.ramalho added a comment. I don't mind having it for release builds as well, why are you applying it only for debug builds? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86223/new/ https://reviews.llvm.org/D86223 __

[PATCH] D86223: [analyzer][z3] Use more elaborate z3 variable names in debug build

mikhail.ramalho requested changes to this revision. mikhail.ramalho added a comment. This revision now requires changes to proceed. In D86223#2231991 , @steakhal wrote: > In D86223#2231959 , @mikhail.ramalho > wrot

[PATCH] D86223: [analyzer][z3] Use more elaborate Z3 variable names

mikhail.ramalho accepted this revision. mikhail.ramalho added a comment. This revision is now accepted and ready to land. LGTM! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86223/new/ https://reviews.llvm.org/D86223 __

[PATCH] D96090: [analyzer] Replace StoreManager::CastRetrievedVal with SValBuilder::evalCast

mikhail.ramalho added a comment. I'm glad to see these patches, the SMT API will benefit greatly from them! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96090/new/ https://reviews.llvm.org/D96090 ___ cfe-commits mailing list cfe-commits@list

[PATCH] D140891: [analyzer] Fix assertion failure in SMT conversion for unary operator on floats.

mikhail.ramalho accepted this revision. mikhail.ramalho added a comment. This revision is now accepted and ready to land. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D140891/new/ https://reviews.llvm.org/D140891

[PATCH] D62445: [test] Fix plugin tests

mikhail.ramalho added a comment. Herald added a subscriber: Charusso. Hi, I just found this revision. Could you point out how can I run the CSA tests with Z3 as backend? We used to do `$ ninja check-clang-analyzer-z3`, however, it now fails and suggests: $ ninja check-clang-analyzer-z3 nin

[PATCH] D28955: [analyzer] Enable support for symbolic extension/truncation

mikhail.ramalho added a comment. I can give some help here, but my time is quite limited as well :/ Let me at least rebase against master. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D28955/new/ https://reviews.llvm.org/D28955 ___ cfe-com

[PATCH] D73062: [analyzer] Simplify BoolAssignmentChecker

mikhail.ramalho created this revision. mikhail.ramalho added a reviewer: NoQ. Herald added subscribers: cfe-commits, Charusso. Herald added a project: clang. mikhail.ramalho retitled this revision from "Simplify BoolAssignmentChecker" to "[analyzer] Simplify BoolAssignmentChecker". Herald added su

[PATCH] D28955: [analyzer] Enable support for symbolic extension/truncation

mikhail.ramalho updated this revision to Diff 239186. mikhail.ramalho added a comment. Herald added subscribers: llvm-commits, hiraditya. Herald added a project: LLVM. Two changes: - Moved the BoolAssignmentChecker changes to separate revision (D73062 ). - Rebase

[PATCH] D73062: [analyzer] Simplify BoolAssignmentChecker

mikhail.ramalho updated this revision to Diff 239397. mikhail.ramalho added a comment. Update the condition to flag an issue. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73062/new/ https://reviews.llvm.org/D73062 Files: clang/lib/StaticAnalyzer/Checkers/BoolAssignmentChecker.cpp I

[PATCH] D36610: [Tooling] Add option to getFullyQualifiedName using a custom PritingPolicy

mikhail.ramalho added a comment. Should we keep just the version with the custom printing policy then? https://reviews.llvm.org/D36610 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D145584: [libc] Add support for setjmp and longjmp in riscv

mikhail.ramalho updated this revision to Diff 507700. mikhail.ramalho marked 6 inline comments as done. mikhail.ramalho added a comment. Herald added a project: clang. Herald added a subscriber: cfe-commits. Address comments Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION http

[PATCH] D145584: [libc] Add support for setjmp and longjmp in riscv

mikhail.ramalho added inline comments. Comment at: libc/src/setjmp/riscv64/longjmp.h:56 + + LIBC_INLINE_ASM("seqz %0, %1" : "+r"(buf) : "r"(val) :); + LIBC_INLINE_ASM("add %0, %0, %1" : "+r"(buf) : "r"(val), "r"(buf) :); sivachandra wrote: > Why is this require

[PATCH] D145584: [libc] Add support for setjmp and longjmp in riscv

mikhail.ramalho added inline comments. Comment at: libc/src/setjmp/riscv64/longjmp.cpp:54-55 + + LIBC_INLINE_ASM("seqz %0, %1" : "+r"(buf) : "r"(val) :); + LIBC_INLINE_ASM("add %0, %0, %1" : "+r"(buf) : "r"(val), "r"(buf) :); +} sivachandra wrote: > Your commen

[PATCH] D145584: [libc] Add support for setjmp and longjmp in riscv

mikhail.ramalho updated this revision to Diff 508187. mikhail.ramalho added a comment. Update return Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D145584/new/ https://reviews.llvm.org/D145584 Files: clang/docs/tools/clang-formatted-files.txt l

[PATCH] D83660: [analyzer] Fix a crash for dereferencing an empty llvm::Optional variable in SMTConstraintManager.h.

mikhail.ramalho added a comment. Indeed it looks like a copy & paste error, I'm surprised no one found it earlier. Regarding the tests, we used to have `make check-clang-analysis-z3` (or something similar) that would run only the analyzer's tests, but using Z3 as the constraint solver. It look