[all-commits] [llvm/llvm-project] 918bda: [analyzer] Do not assume that all pointers have th...

vabridgers via All-commits all-commits at lists.llvm.org
Fri Jul 16 01:23:23 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 918bda1241202d0480c6d94ec8f72c483d77a06c
      https://github.com/llvm/llvm-project/commit/918bda1241202d0480c6d94ec8f72c483d77a06c
  Author: Vince Bridgers <vince.a.bridgers at gmail.com>
  Date:   2021-07-16 (Fri, 16 Jul 2021)

  Changed paths:
    M clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
    A clang/test/Analysis/solver-sym-simplification-ptr-bool.cl

  Log Message:
  -----------
  [analyzer] Do not assume that all pointers have the same bitwidth as void*

This change addresses this assertion that occurs in a downstream
compiler with a custom target.

```APInt.h:1151: bool llvm::APInt::operator==(const llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Comparison requires equal bit widths"'```

No covering test case is susbmitted with this change since this crash
cannot be reproduced using any upstream supported target. The test case
that exposes this issue is as simple as:

```lang=c++
  void test(int * p) {
    int * q = p-1;
    if (q) {}
    if (q) {} // crash
    (void)q;
  }
```

The custom target that exposes this problem supports two address spaces,
16-bit `char`s, and a `_Bool` type that maps to 16-bits. There are no upstream
supported targets with similar attributes.

The assertion appears to be happening as a result of evaluating the
`SymIntExpr` `(reg_$0<int * p>) != 0U` in `VisitSymIntExpr` located in
`SimpleSValBuilder.cpp`. The `LHS` is evaluated to `32b` and the `RHS` is
evaluated to `16b`. This eventually leads to the assertion in `APInt.h`.

While this change addresses the crash and passes LITs, two follow-ups
are required:
  1) The remainder of `getZeroWithPtrWidth()` and `getIntWithPtrWidth()`
     should be cleaned up following this model to prevent future
     confusion.
  2) We're not sure why references are found along with the modified
     code path, that should not be the case. A more principled
     fix may be found after some further comprehension of why this
     is the case.

Acks: Thanks to @steakhal and @martong for the discussions leading to this
fix.

Reviewed By: NoQ

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




More information about the All-commits mailing list