================ @@ -1356,30 +1356,62 @@ Static Analyzer New features ^^^^^^^^^^^^ -- Now CSA models `__builtin_*_overflow` functions. (#GH102602) +- The ``__builtin_*_overflow`` functions are now properly modeled. (#GH102602) -- MallocChecker now checks for ``ownership_returns(class, idx)`` and ``ownership_takes(class, idx)`` - attributes with class names different from "malloc". Clang static analyzer now reports an error - if class of allocation and deallocation function mismatches. +- ``unix.Malloc`` now checks for ``ownership_returns(class, idx)`` and ``ownership_takes(class, idx)`` + attributes with class names different from "malloc". It now reports an error + if the class of allocation and deallocation function mismatches. `Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#unix-mismatcheddeallocator-c-c>`__. - Function effects, e.g. the ``nonblocking`` and ``nonallocating`` "performance constraint" attributes, are now verified. For example, for functions declared with the ``nonblocking`` - attribute, the compiler can generate warnings about the use of any language features, or calls to + attribute, the compiler can generate warnings about the use of any language features or calls to other functions, which may block. - Introduced ``-warning-suppression-mappings`` flag to control diagnostic - suppressions per file. See `documentation <https://clang.llvm.org/docs/WarningSuppressionMappings.html>_` for details. + suppressions per file. See `documentation <https://clang.llvm.org/docs/WarningSuppressionMappings.html>`__ for details. + +- Started to model GCC asm statements in some basic way. (#GH103714, #GH109838) Crash and bug fixes ^^^^^^^^^^^^^^^^^^^ - In loops where the loop condition is opaque (i.e. the analyzer cannot determine whether it's true or false), the analyzer will no longer assume - execution paths that perform more that two iterations. These unjustified + execution paths that perform more than two iterations. These unjustified assumptions caused false positive reports (e.g. 100+ out-of-bounds reports in the FFMPEG codebase) in loops where the programmer intended only two or three steps but the analyzer wasn't able to understand that the loop is limited. + Read the `RFC <https://discourse.llvm.org/t/loop-handling-improvement-plans/80417/17>`_ + for details. (#GH119388) ---------------- NagyDonat wrote:
```suggestion (#GH119388) ``` I wouldn't link the loop improvement discourse thread here, because I think the (fairly detailed) github PR description and its discussion is sufficient for understanding the goals of this change -- while the discourse thread mostly contains confusing descriptions of obsolete, abandoned plans that are just tangentially related to this commit. https://github.com/llvm/llvm-project/pull/124798 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
