llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
27.97k stars 11.54k forks source link

False positive - Assigned value is garbage or undefined #8285

Open llvmbot opened 14 years ago

llvmbot commented 14 years ago
Bugzilla Link 7913
Version unspecified
OS MacOS X
Attachments Code exhibiting issue
Reporter LLVM Bugzilla Contributor
CC @belkadan,@tkremenek,@seanm,@xuzhongxing

Extended Description

The attached sample code comprises two versions of a short routine called 'shrink'. They should be equivalent but the second one produces a false positive 'Assigned value is garbage or undefined'. Such a warning would make sense if the value of op->npar was a volatile, but it isn't.

Thanks.

Charles


$ /Developer/usr/bin/clang -v --analyze /Users/X/Documents/clang-bug/main.c -o foo.html Apple clang version 1.5 (tags/Apple/clang-60) Target: x86_64-apple-darwin10 Thread model: posix "/Developer/usr/bin/clang" -cc1 -triple x86_64-apple-darwin10.0.0 -analyze -disable-free -disable-llvm-verifier -main-file-name main.c -analyzer-store=region -analyzer-opt-analyze-nested-blocks -analyzer-check-dead-stores -analyzer-check-objc-mem -analyzer-eagerly-assume -analyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars -analyzer-output plist -w -pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -v -resource-dir /Developer/usr/lib/clang/1.5 -ferror-limit 19 -fmessage-length 103 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o foo.html -x c /Users/X/Documents/clang-bug/main.c clang -cc1 version 1.5 based upon llvm 2.7svn hosted on x86_64-apple-darwin10

include "..." search starts here:

include <...> search starts here:

/Developer/usr/lib/clang/1.5/include /usr/local/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. /Users/X/Documents/clang-bug/main.c:16:3: warning: Assigned value is garbage or undefined t[i] = s[i]; ^ ~~~~ 1 warning generated.

tkremenek commented 12 years ago

Created attachment 8949 [details] Similar false positive after casting array of uint16_t to uint8_t*

I hope this belongs here, if not I apologize.

Ideally, this would be a separate bug report, but that's fine.

cloned to rdar://problem/11966749

llvmbot commented 12 years ago

Similar false positive after casting array of uint16_t to uint8_t* I hope this belongs here, if not I apologize.

llvmbot commented 12 years ago

Indeed, I can confirm that my example doesn't give an error anymore. Thanks to whoever fixed it :)

belkadan commented 13 years ago

I can't get an error for the case without floating-point involvement on ToT. For the one with, here's what I see as the main problem, or at least a low-hanging fruit: if you perform the same cast twice, you get the same result. Is there any way we can model that?

llvmbot commented 13 years ago

Minimal example not using doubles I have a similar issue, without any doubles. I am attaching a very minimal test case.

tkremenek commented 14 years ago

I think we lose the control-dependency here because 'N' is assigned a conjured value. We aren't modeling the field value because it is a double.

llvmbot commented 14 years ago

assigned to @tkremenek