[PATCH] D104550: [analyzer] Implement getType for SVal

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D104550#3139239 <https://reviews.llvm.org/D104550#3139239>, @stevewan wrote:

> In D104550#2849582 <https://reviews.llvm.org/D104550#2849582>, @vsavchenko wrote:
>
>> In D104550#2849561 <https://reviews.llvm.org/D104550#2849561>, @DavidSpickett wrote:
>>
>>> @vsavchenko One of the added tests is failing on our 32 bit Armv7 Thumb bot: https://lab.llvm.org/buildbot/#/builders/170/builds/61
>>>
>>>   /home/tcwg-buildslave/worker/clang-thumbv7-full-2stage/llvm/clang/unittests/StaticAnalyzer/SValTest.cpp:169: Failure
>>>   Expected equality of these values:
>>>     Context.UnsignedLongTy
>>>       Which is: unsigned long
>>>     A.getType(Context)
>>>       Which is: unsigned int
>>>   [  FAILED  ] SValTest.GetLocAsIntType (22 ms)
>>>   [----------] 1 test from SValTest (22 ms total)
>>>
>>> A 32/64 bit issue?
>>
>> Hi @DavidSpickett , thanks for looking into this!
>> This patch was almost instantly followed by https://github.com/llvm/llvm-project/commit/b2842298cebf420ecb3750bf309021a7f37870c1 which fixed the issue.  Please, let me know, if you still see it after that commit!
>
> Sorry for posting to this slightly aged thread. I'm seeing a similar error of this on 32 bit AIX PPC, where `getUIntPtrType()` returns unsigned long, so the aforementioned follow-on patch no longer applies. The results from `getIntTypeForBitwidth()` seem unreliable in certain cases (e.g. int vs long in ILP32), and I couldn't think of a good way around it. Have you had any future plans on mitigating such problems?

Hi there, what is the exact target triple?
I wonder if it would be possible to create a new unit test case where we pass somehow the target triple to `runCheckerOnCode`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104550/new/

https://reviews.llvm.org/D104550