[PATCH] D57230: [analyzer] Toning down invalidation a bit

NoQ added a comment. Herald added a subscriber: Charusso. Hmm, here's another one: struct ListInfo { struct ListInfo *next; }; struct X { struct ListInfo li; int i; }; void list_add(struct ListInfo *list, struct ListInfo *item); void foo(struct ListInfo *list) {

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun added a comment. Herald added a subscriber: jdoerfert. Experimental patch is up in https://reviews.llvm.org/D58121 Unfortunately, it is not perfect yet. Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57230/new/ https://reviews.llvm.org/D57230 _

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun added a comment. I think I might have a theory, but I would like to discuss it as I am not familiar with the internals bindings. My theory is the following: when we store the bindings, we store them in a map where the key is a base region. So when we try to look the bindings up wit

[PATCH] D57230: [analyzer] Toning down invalidation a bit

NoQ added a comment. That's the one: typedef __typeof(sizeof(int)) size_t; void *malloc(size_t); void escape(int **); struct S { int *ptr; }; void foo() { struct S s1; s1.ptr = malloc(sizeof(int)); escape(&s1.ptr); } After the patch the allocated symbol no

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun added a comment. In D57230#1387834 , @NoQ wrote: > There seem to be a few regressions - weird memory leaks of inner objects in > C++ destructors. Trying to investigate/reproduce. Oh, that is unfortunate. Feel free to share a repro as soon as y

[PATCH] D57230: [analyzer] Toning down invalidation a bit

NoQ added a comment. There seem to be a few regressions - weird memory leaks of inner objects in C++ destructors. Trying to investigate/reproduce. Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57230/new/ https://reviews.llvm.org/D57230

[PATCH] D57230: [analyzer] Toning down invalidation a bit

NoQ added a comment. Herald added a project: LLVM. Hmm. `writes_to_superobject`? Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57230/new/ https://reviews.llvm.org/D57230 ___ cfe-commits mailing list cfe-commits@lists.

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun added a comment. Thanks for all the reviews. Do you have any preference about the spelling of the annotation mentioned in the description? There were two ideas so far: `uses_offsetof`, `may_use_offsetof` While I like those, I wonder if it is a good idea to have `offsetof` in the name

[PATCH] D57230: [analyzer] Toning down invalidation a bit

This revision was automatically updated to reflect the committed changes. Closed by commit rL352473: [analyzer] Toning down invalidation a bit (authored by xazax, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D57230?vs=183702&id=18404

[PATCH] D57230: [analyzer] Toning down invalidation a bit

NoQ accepted this revision. NoQ added a comment. In D57230#1373721 , @xazax.hun wrote: > Do you think I should try to reduce additional files? Aha, ok, it reduced an interesting positive into a non-interesting positive. So i guess my method only works w

[PATCH] D57230: [analyzer] Toning down invalidation a bit

george.karpenkov added a comment. I'm in favor of this change, I never understood how invalidating a field invalidates entire structure. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57230/new/ https://reviews.llvm.org/D57230 ___ cfe-commi

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun added a comment. I tried to creduce one file where the result differed and this is the result: typedef struct { int a; int b } c; d; e(c *f) { d < f->a; c g; h(&g.b); e(&g); } I think this the core idea is quite straightforward but this example is a bi

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun added a comment. In D57230#1372523 , @NoQ wrote: > In D57230#1372488 , @xazax.hun wrote: > > > In D57230#1372275 , @NoQ wrote: > > > > > > > > > > > Do you have suc

[PATCH] D57230: [analyzer] Toning down invalidation a bit

NoQ added a comment. In D57230#1372488 , @xazax.hun wrote: > In D57230#1372275 , @NoQ wrote: > > > > > > Do you have success reducing false positives using creduce? My problem > usually is that we cannot tell if a

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun updated this revision to Diff 183702. xazax.hun added a comment. - Added some tests CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57230/new/ https://reviews.llvm.org/D57230 Files: lib/StaticAnalyzer/Core/CallEvent.cpp test/Analysis/call-invalidation.cpp test/Analysis/cx

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun marked 2 inline comments as done. xazax.hun added a comment. In D57230#1372275 , @NoQ wrote: > Could you share reproducible examples for these, probably in the form of > FIXME tests? Given that they are "regressions", they are easy to creduce do

[PATCH] D57230: [analyzer] Toning down invalidation a bit

NoQ added a comment. Thanks! A surprise, to be sure :) I'll try to test this on my set of projects as well :) > Most of the extra results are not false positive due to the less invalidation > but other reasons, so we could focus on those problems instead of them being > hidden. Could you shar

[PATCH] D57230: [analyzer] Toning down invalidation a bit

Szelethus accepted this revision. Szelethus edited reviewers, added: NoQ; removed: dergachev.a. Szelethus added a subscriber: NoQ. Szelethus added a comment. This revision is now accepted and ready to land. Let's also have a link to your cfe-dev mail in this patch: http://lists.llvm.org/pipermail

[PATCH] D57230: [analyzer] Toning down invalidation a bit

xazax.hun created this revision. xazax.hun added reviewers: dergachev.a, george.karpenkov, Szelethus. xazax.hun added a project: clang. Herald added subscribers: gamesh411, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, whisperity. This is a patch for the fo