[all-commits] [llvm/llvm-project] aa454d: [analyzer] LValueToRValueBitCasts should evaluate ...

[Balazs Benics via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: aa454dda2eed4e71081bc57b1f32dfce2486b177
      https://github.com/llvm/llvm-project/commit/aa454dda2eed4e71081bc57b1f32dfce2486b177
  Author: Balazs Benics <balazs.benics at sigmatechnology.se>
  Date:   2021-07-01 (Thu, 01 Jul 2021)

  Changed paths:
    M clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
    A clang/test/Analysis/builtin_bitcast.cpp

  Log Message:
  -----------
  [analyzer] LValueToRValueBitCasts should evaluate to an r-value

Previously `LValueToRValueBitCast`s were modeled in the same way how
a regular `BitCast` was. However, this should not produce an l-value.
Modeling bitcasts accurately is tricky, so it's probably better to
model this expression by binding a fresh conjured value.

The following code should not result in a diagnostic:
```lang=C++
  __attribute__((always_inline))
  static inline constexpr unsigned int_castf32_u32(float __A) {
    return __builtin_bit_cast(unsigned int, __A); // no-warning
  }
```

Previously, it reported
`Address of stack memory associated with local variable '__A' returned
to caller [core.StackAddressEscape]`.

Differential Revision: https://reviews.llvm.org/D105017

Reviewed by: NoQ, vsavchenko


  Commit: 55662b24a4755680e4fd34dc22a3dd555fdb1291
      https://github.com/llvm/llvm-project/commit/55662b24a4755680e4fd34dc22a3dd555fdb1291
  Author: Balazs Benics <balazs.benics at sigmatechnology.se>
  Date:   2021-07-01 (Thu, 01 Jul 2021)

  Changed paths:
    M clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
    M clang/test/Analysis/casts.c

  Log Message:
  -----------
  [analyzer][NFC] Inline ExprEngine::handleLVectorSplat()

It seems like ExprEngine::handleLVectorSplat() was used at only 2
places. It might be better to directly inline them for readability.

It seems like these cases were not covered by tests according to my
coverage measurement, so I'm adding tests as well, demonstrating that no
behavior changed.
Besides that, I'm handling CK_MatrixCast similarly to how the rest of
the unhandled casts are evaluated.

Differential Revision: https://reviews.llvm.org/D105125

Reviewed by: NoQ


Compare: https://github.com/llvm/llvm-project/compare/820ced136280...55662b24a475