search for: malloccheck

Hi Tim, You seem to be working around BLX support on ARM, and this linker error has cropped up on our buildbot: http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/3526 llvm/tools/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp: (.text._ZN5clang4ento24ProgramStatePartialTraitIN4llvm12ImmutableMapIPKNS0_7SymExprEN12_GLOBAL__N_111ReallocPairENS2_16ImutKeyValueInfoIS6_S8_EEEEE13DeleteContextEPv+0x88): relocation truncated to fit: R_ARM_THM_JUMP24 against symbol `operator delete(void*)@@GLIBCXX_3.4' defined in .te...

On 18 May 2016 at 17:32, Tim Northover <t.p.northover at gmail.com> wrote: > That's the thing: this shouldn't have changed at all recently. We emit > "b.w dest" with an R_ARM_THM_JUMP24 reloc. The linker then needs a > veneer if dest is out of range or an ARM function. Peter has just reminded me the fact that the relocation itself is in libstdc++, not on the

On 18 May 2016 at 15:12, Tim Northover <t.p.northover at gmail.com> wrote: > I don't suppose you could grab a -save-temps output for MallocChecker.cpp? Not from the bot any more. I didn't expect this to be a heisenbug. And I'm having trouble replicating it on my other machine. > I think we only produce R_ARM_THM_JUMP24 for tail calls. The veneer is > then needed if a mode change is required because there's no "bx (...

...CHEN- Zhihan/Compiler). I've gone through the llvm tutorial and I am currently checking some of the static checkers and learning building a new checker. I am wondering if it is possible to treat this problem as a variation of use-after-free problem so that we may make some adaptations based on MallocChecker. I also think that we can check free the string from the raw pointer problem. This project is rather interesting and I am really willing to make some contribution to the LLVM community. Thanks, Zhihan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://li...

Hi LLVM developers, I am not available from February 11th to February 25th due to Chinese Spring Festival and my sincere thanks goto: Anna Zaks:     She lead me to the LLVM family and reviewed my patch for clang analyzer MallocChecker carefully and patiently. Дуже дякую Artem Dergachev:     He reviewed my patches for clang analyzer some Checkers carefully. Большое спасибо Dylan McKay:     He reviewed my patches for AVR Target. Thanks a lot! Rui Ueyama:     He taught me how to migrate AVR for LLD. どうもありがとう Duncan San...

Hi LLVM developers, Don't be quiet :) we need your suggestions for supporting custom CCState, CCAssignFn in D41700. And also RegisterBank in D41653. because it needs to consider about how to support variable-sized register classes concept implemented in D24631. And I think you might have same question when porting to GlobalISel for your Targets, so please give us some directions, thanks

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,