[clang] Static analyzer crash with just core checkers

[omern1]

https://gcc.godbolt.org/z/aMnzcs6Eb

// > clang -O0 -Xclang -analyzer-checker=core -Xclang -analyze ./input.cpp

enum class a { b };
char c[sizeof(a)];
struct {
  operator a() { return __builtin_bit_cast(a, c); }
} d;
void e() {
  switch (d)
  case a::b:
}

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: Nabeel Omer (omern1)

https://gcc.godbolt.org/z/aMnzcs6Eb

// > clang -O0 -Xclang -analyzer-checker=core -Xclang -analyze ./input.cpp

enum class a { b };
char c[sizeof(a)];
struct {
  operator a() { return __builtin_bit_cast(a, c); }
} d;
void e() {
  switch (d)
  case a::b:
}

[steakhal]

Confirmed.

enum class Enum : char { b };
Enum convert() {
    char c[1] = {};
    static_assert(sizeof(Enum) == 1);
    return __builtin_bit_cast(Enum, c);
}
void top() {
    switch (convert()) {
        case Enum::b:
            return;
    }
}

[steakhal]

Assertion 'assumeInclusiveRange' is not implementedfor this NonLoc.
Stack trace:

 #8 SimpleConstraintManager::assumeInclusiveRangeInternal(ProgramStateRef, NonLoc, APSInt const&, APSInt const&, bool)
 #9 ConstraintManager::assumeDualImpl()
#10 ConstraintManager::assumeInclusiveRangeDual(ProgramStateRef, NonLoc, APSInt const&, APSInt const&)
#11 ExprEngine::processSwitch(SwitchNodeBuilder&)
#12 HandleBlockExit(clang::CFGBlock const*, ExplodedNode*)

[OCHyams]

I don't know anything about how the static analyzer works, but this similar test case crashes with a slightly different stack trace. I have no idea whether a fix for one would fix the other, so thought I'd note it just in case.

using a = int (*)(int);
char b[sizeof(a)];
void c() { __builtin_bit_cast(a, b)(int()); }

This one fails in clang::ento::SimpleConstraintManager::assumeAux(class llvm::IntrusiveRefCntPtr<class clang::ento::ProgramState const>, class clang::ento::NonLoc, bool) SimpleConstraintManager.cpp:68

[steakhal]

Well, personally I'm not particularly interested in fixing bitcast crashes. And I always wonder if these come from realworld code. If they would, then I could reconsider my position, but for now it's not too interesting.
Did you simplify this from fuzzing or from some real code?

[OCHyams]

And I always wonder if these come from realworld code

These two cases are reduced from real world code, not from fuzzing

[wjristow]

And I always wonder if these come from realworld code

These two cases are reduced from real world code, not from fuzzing

I don't have experience working in the static analyzer, but this is still impacting us in the original realworld code. @steakhal , do you have any insight on this?

[NagyDonat]

Note that the technical implementation behind the assumeInclusiveRange function family is (in my opinion) a bit "cursed" -- it abuses the overflow behavior to express the $value \in range$ condition in a concise but counter-intuitive way. I hope that I can gradually eliminate it from the codebase by switching to other, more natural approaches.

(However, this is not immediately relevant for this bug -- my long-term plans are too slow to be a practical solution.)

[wjristow]

Thanks @NagyDonat for the update. Given that a fix doesn't look like it's pending soon, we will work around this problem for now.