[analyzer] Aliasing leads to analyzer failures

Hello, I think this case is very similar (if not the same) to case 2 described in this fogbugz case: https://bugs.llvm.org/show_bug.cgi?id=43364.

Artem, could you confirm? Any tips on where to get started looking at this one?

clang -cc1 -analyze -analyzer-checker=core test.c
test.c:13:7: warning: Branch condition evaluates to a garbage value
if (p[1])
^~~~
1 warning generated.

The reproducer …
struct S {
unsigned short val;
};
int main(void)
{
struct S var = { 0x1122 };
char *p = (char *)&var;
int x = 0;
if (p[0])
x+=1;
if (p[1])
x+=1;
return x;
}

Vince and I had a discussion about this in another channel. I am summarizing the relevant information here, so if anybody interested in this mailing list could follow up.

This issue seems to be a known problem, i.e we have a technical debt with handling casts:

Track type information through casts more precisely.
The DynamicTypePropagation checker is in charge of inferring a region’s dynamic type based on what operations the code is performing. Casts are a rich source of type information that the analyzer currently ignores.

In the DynamicTypePropagation checker’s checkPostStmt(CastExpr*) function there is modeling only for some ObjC casts:

const auto *OrigObjectPtrType = OriginType->getAs();
const auto *DestObjectPtrType = DestType->getAs();

if (!OrigObjectPtrType || !DestObjectPtrType)
return;

Also, this is really suspicious too:
/// TODO: Handle explicit casts.
/// Handle C++ casts.
///
/// Precondition: the cast is between ObjCObjectPointers.
ExplodedNode *DynamicTypePropagation::dynamicTypePropagationOnCasts(

Gabor

No-no, this is most likely https://bugs.llvm.org/show_bug.cgi?id=44114.

> Any tips on where to get started looking at this one?

In the exploded graph (;

Like, seriously, it's usually very hard to guess what exactly is going on; bisecting the ill-formed states in the exploded graph dump is the only reliable way of debugging these things.