3 Commits

Author SHA1 Message Date
Ziqing Luo
41229581a4
[analyzer] Fix crashing __builtin_bit_cast (#139188)
Previously, CSA did not handle __builtin_bit_cast correctly. It
evaluated the LvalueToRvalue conversion for the casting expression,
but did not actually convert the value of the expression to be of the
destination type.
This commit fixes the problem.

rdar://149987320
2025-05-13 10:24:02 -07:00
Balazs Benics
51d15d13de
[analyzer] Fix assertion failure in CXXInstanceCall::getCXXThisVal (#70837)
Workaround the case when the `this` pointer is actually a `NonLoc`, by
returning `Unknown` instead.
The solution isn't ideal, as `this` should be really a `Loc`, but due to
how casts work, I feel this is our easiest and best option.

As this patch presents, I'm evaluating a cast to transform the `NonLoc`.
However, given that `evalCast()` can't be cast from `NonLoc` to a
pointer type thingy (`Loc`), we end up with `Unknown`.
It is because `EvalCastVisitor::VisitNonLocSymbolVal()` only evaluates
casts that happen from NonLoc to NonLocs.

When I tried to actually implement that case, I figured:
1) Create a `SymbolicRegion` from that `nonloc::SymbolVal`; but
`SymbolRegion` ctor expects a pointer type for the symbol.
2) Okay, just have a `SymbolCast`, getting us the pointer type; but
`SymbolRegion` expects `SymbolData` symbols, not generic `SymExpr`s, as
stated:

> // Because pointer arithmetic is represented by ElementRegion layers,
> // the base symbol here should not contain any arithmetic.

3) We can't use `ElementRegion`s to perform this cast because to have an
`ElementRegion`, you already have to have a `SubRegion` that you want to
cast, but the point is that we don't have that.

At this point, I gave up, and just left a FIXME instead, while still
returning `Unknown` on that path.
IMO this is still better than having a crash.

Fixes #69922
2023-11-04 11:11:24 +01:00
Balazs Benics
aa454dda2e [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
2021-07-01 10:54:22 +02:00