Page MenuHomePhabricator

[scan-build] fix warnings emitted on LLVM TargetRecip code base
AbandonedPublic

Authored by apelete on May 5 2016, 6:51 AM.

Details

Reviewers
spatel
Summary

Fix logic error warnings of the type "called C++ object pointer is
null" emitted by Clang Static Analyzer on the following files:

  • lib/Target/TargetRecip.cpp.

Signed-off-by: Apelete Seketeli <apelete@seketeli.net>

Diff Detail

Event Timeline

apelete updated this revision to Diff 56280.May 5 2016, 6:51 AM
apelete retitled this revision from to [scan-build] fix warnings emitted on LLVM TargetRecip code base Fix logic error warnings of the type "called C++ object pointer is null" emitted by Clang Static Analyzer on the following files: - lib/Target/TargetRecip.cpp..
apelete updated this object.
apelete added a reviewer: spatel.
apelete added a subscriber: llvm-commits.
apelete retitled this revision from [scan-build] fix warnings emitted on LLVM TargetRecip code base Fix logic error warnings of the type "called C++ object pointer is null" emitted by Clang Static Analyzer on the following files: - lib/Target/TargetRecip.cpp. to [scan-build] fix warnings emitted on LLVM TargetRecip code base.May 5 2016, 7:44 AM
apelete updated this object.
dblaikie added inline comments.
lib/Target/TargetRecip.cpp
74

Does msan ever diagnose this as use-of-uninitialized? Or is this only used in the codepaths where it is initialized?

spatel added inline comments.May 5 2016, 12:13 PM
lib/Target/TargetRecip.cpp
74

The intent was that RefSteps could only be used when RefStepString is valid and therefore not empty (see 'report_fatal_error' just above this). Could this be a false positive from scan-build?

apelete added inline comments.May 9 2016, 9:57 AM
lib/Target/TargetRecip.cpp
74

This one looks like a false positive indeed: scan-build seems unable to see that RefSteps is initialized in parseRefinementStep() below.
Should I remove the initializations here and ignore the warnings ?

spatel added inline comments.May 9 2016, 10:10 AM
lib/Target/TargetRecip.cpp
74

Yes, initializing to '0' could mask an actual problem. You could add asserts of the RefSteps value [0-9] just after the calls to parseRefinementStep() if that would make scan-build happier.

apelete added inline comments.May 9 2016, 11:58 AM
lib/Target/TargetRecip.cpp
74

Assert on RefSteps <= 9 does not suppress the "assigned value is garbage or undefined" warnings on lines 105, 155 and 161 below in this case.
Ignoring the warnings in this file sound like the sanest thing to do.

spatel added inline comments.May 9 2016, 3:00 PM
lib/Target/TargetRecip.cpp
74

Right - if we can't avoid the false positives, let's leave it alone.

spatel edited edge metadata.May 20 2016, 11:30 AM

abandon?

apelete abandoned this revision.May 21 2016, 5:41 AM