> Unfortunately we have no ability to share our code before it satisfies some > quality level... The llvm developer policy encourages incremental development. If you cannot send patches before they go though the approval process, maybe you could seek guidance while developing by posting questions on the mailing list and split the patch into logical pieces when sending for review? For example, in this case, the ExternalSym is something that would come in separately with it's own tests as justification. We should also discuss if that's the best approach to suppress the false positives.
>You are correct in your assumption about ExternalSym goals. But there are some >cases where analyzer fails to determine right value for a symbol, i.e two >alerts from android >codebase: I hope there could be better ways of handling these than a checker keeping a table of symbols that are not handled well by the analyzer. (The current approach does not solve the underlying issues and it introduces overhead for all checkers.) Looks like there are various sources of false positives.. >This alert happens because analyzer have no information about num_shaders and >while cross_validate_globals proccessing assumes that num_shaders can be 0. >But actually >it's never happened because num_shaders is checked for 0 every >time before link_intrastage_shaders calling >(external/mesa3d/src/glsl/linker.cpp, lines 1602 and 1617). This is about an inlined function adding constraints that are not valid for all input values? Would it be possible to construct a small example/test case for this? You can use the debug checkers to show that a particular variable does not have the right value, see docs/analyzer/DebugChecks.rst? We have added some heuristics for null pointer dereference, where we do not count in the null checks coming from the inlined functions (inlined defensive checks). However, this case might be more complicated. >native/libs/utils/String8.cpp) and class member mString is assumed to be 0. >So, when value.length() is called(line 66) underflow happens and (0 - 1) is >returned. Further addition 1 results in FP overflow. It's hard me to tell what this issue is - not all code is available. Again, could you construct a small example and show that the value is wrong with the debug checker? If we fail to inline a constructor, a value should be underconstrained, not '0'. http://reviews.llvm.org/D4066 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
