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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
