This is an archive of the discontinued LLVM Phabricator instance.

[analyzer][NFC] Re-enable skipped SValTests by relaxing expectations
ClosedPublic

Authored by steakhal on Dec 8 2021, 7:43 AM.

Details

Summary

Some tests were skipped in D114454 to resolve test failures on some
platforms, where the pointers have different bitwidth than expected.
This patch re-enables these tests, by relaxing the requirements on the
types of the SVal.

The issue:
There is no way to reconstruct the type of the SVal perfectly
accurately, since there could be multiple types having the required
bitwidth and signedness.
Consider platforms where int and long have the same bitwidth.
Additionally, we need to be careful about casting a pointer to an
integral representation, because we don't know what smallest integral
type can represent that.

To workaround these issues, I propose enforcing a type that has the
same signedness and bitwidth as the expected type, instead of perfect
equality.

In the GetLocAsIntType test, in case of pointer-to-integral casts
I'm using the widest standard integral type (long long) to make sure
that the pointer can be represented by the type without losing
precision. This won't affect the test in any meaningful way, since the
type of the lvalue remained the same.

In one case, I had to replace getUIntPtrType() with UnsignedLongTy
because on some platforms getUIntPtrType() is different then `long
int`.

In this patch, I also enforce that the tests must compile without
errors, to prevent narrowing conversions in the future.

Diff Detail

Event Timeline

steakhal created this revision.Dec 8 2021, 7:43 AM
steakhal requested review of this revision.Dec 8 2021, 7:43 AM
stevewan added inline comments.Jan 5 2022, 10:50 AM
clang/unittests/StaticAnalyzer/SValTest.cpp
177–179

Okay this reminded me that I wanted to ask this dumb question. Don't the assignments eventually do the implicit down-casting? Is it fine because we are not dealing with anything concrete and just doing static analysis over the code?

stevewan accepted this revision.Jan 5 2022, 10:55 AM

As emphasized in the description, we can't get the exact type of the SVal, and I agree that checking for the same signedness and bitwidth is our best bet. LGTM given that my question is addressed. Thanks.

This revision is now accepted and ready to land.Jan 5 2022, 10:55 AM

Thanks for the review @stevewan!
Let me know if I managed to answer your question.

clang/unittests/StaticAnalyzer/SValTest.cpp
177–179

I think the problem is that this is a c-style reinterpret cast. And that must operate on equal bitwidth (or casting to something even larger) types.
So, if I recall correctly, this code did not compile on all targetted platforms, thus I decided to use a slightly wider type to accommodate for that.

From the CSA's standpoint, it shouldn't matter. The value of x will be eventually narrowed to a long int.
If the pointer has the same bitwidth as long int, then the widening is compensated by the narrowing, binding a directly to x.
If the pointer has the same bitwidth as long long int, then there is no widening, only a narrowing, thus CSA will bind a to (long int)x.

Anyway, since x is a pointer, and AFAIK CSA models pointers as unsigned values, we should get an unsigned value at the end of the day.
But don't quote me on that :D

stevewan added a comment.EditedJan 6 2022, 8:17 AM

Thanks @steakhal for the clarification. Yes my question is answered.

This revision was landed with ongoing or failed builds.Jan 19 2022, 6:16 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJan 19 2022, 6:16 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript