Casting a pointer to a suitably large integral type by reinterpret-cast
should result in the same value as by using the __builtin_bit_cast().
The compiler exploits this: https://godbolt.org/z/zMP3sG683
However, the analyzer does not bind the same symbolic value to these
expressions, resulting in weird situations, such as failing equality
checks and even results in crashes: https://godbolt.org/z/oeMP7cj8q
Previously, in the RegionStoreManager::getBinding() even if T was non-null, we replaced it with TVR->getValueType() in case the MR was TypedValueRegion.
It doesn't make much sense to auto-detect the type if the type is already given.
By not doing the auto-detection, we would just do the right thing and perform the load by that type.
This means that we will cast the value to that type.
So, in this patch, I'm proposing to do auto-detection only if the type was null.
Here is a snippet of code, annotated by the previous and new dump values.
LocAsInteger should wrap the SymRegion, since we want to load the address as if it was an integer.
In none of the following cases should type auto-detection be triggered, hence we should eventually reach an evalCast() to lazily cast the loaded value into that type.
void LValueToRValueBitCast_dumps(void *p, char (*array)[8]) { clang_analyzer_dump(p); // remained: &SymRegion{reg_$0<void * p>} clang_analyzer_dump(array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>} clang_analyzer_dump((unsigned long)p); // remained: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}} clang_analyzer_dump(__builtin_bit_cast(unsigned long, p)); <--------- change #1 // previously: {{&SymRegion{reg_$0<void * p>}}} // now: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}} clang_analyzer_dump((unsigned long)array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}} clang_analyzer_dump(__builtin_bit_cast(unsigned long, array)); <--------- change #2 // previously: {{&SymRegion{reg_$1<char (*)[8] array>}}} // now: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}} }
I think it would make sense to have another RUN line with support-symbolic-integer-casts. In that case I guess we should see (int)(float)x (?).