similar to: [LLVMdev] Clang: strange malloc usage

Hello everyone! I've found strange code in tools/libclang/CIndex.cpp in function clang_tokenize(). Lines 5570*Tokens = (CXToken *)malloc(sizeof(CXToken) * CXTokens.size()); memmove(*Tokens, CXTokens.data(), sizeof(CXToken) * CXTokens.size()); seem weird without checking the result of malloc-function invocation. Since malloc() can return null pointer, this value can be used in memmove

Hello everyone! I'm a newcomer for the great LLVM project. I've started to explore the source code of LLVM project to become more familiar with it, and I've found some strange usage of move semantics in constructor of StringMapImpl( StringMapImpl &&RHS) {...} class in include/llvm/ADT/StringMap.h line 56. Could anyone explain me the purpose of zeroing of all fields of RHS in

On Sun, Oct 23, 2011 at 10:34 PM, James Molloy wrote: > Hi, > > I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. > $ make happiness ... Updated to revision 142790. ... make[4]: Entering directory `/home/ecsardu/LLVM/build-tcclab1/tools/clang/tools/libclang' llvm[4]: Compiling

Hi, Recently I've done some experiments on the LLVM/Clang code and discovered that many of our source files often include unnecessary header files. I wrote a simple tool that eliminates redundant includes and estimates benefits of doing it, and the results were quite nice: for some files we were able to save 90% of compile time! I think we want to apply some of the cleanups I found, but

It's also likely that a lot of '#include "foo.h"' can be replaced with 'class foo;' Especially in the transitive inclusion case, instead of removing the #include entirely. On Wed, Dec 6, 2017 at 8:38 AM, Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I, for one, want faster builds. > > Beyond that though, this seems like obvious

> To find which header files could be removed it scanned the file for "#include" lines and tried to remove them one by one (checking if the file still compiles after the removal). When there were no more include lines to remove, we verified the change with ninja+ninja check. It looks like this makes us rely heavily on transitive header includes -- is that right? Specifically what I

[Sorry about the crosspost. Since this is a clang build question but the build is invoked from the top-level LLVM directory I'm not sure where the question should go.] I've got a clang build against libstdc++ on Linux but I would really like one built against libc++/libc++abi. In other words I'd like to rebuild clang/llvm with clang using libc++ and libc++abi on Linux. I looked at

Hi, I tweaked my scripts to avoid removing includes when it doesn't give any significant benefits, which made the patches significantly smaller. This time the patches should not try to remove includes of header files, which are transitively included from other included header files. The gains mostly remained the same (plus/minus noise), the tables are in the end of the email. I also included

2017-12-09 12:54 GMT-08:00 Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org>: > > > On Dec 8, 2017, at 5:01 PM, Mikhail Zolotukhin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > I tweaked my scripts to avoid removing includes when it doesn't give any > significant benefits, which made the patches significantly smaller. This >

Hi, I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. Cheers, James ________________________________________ From: Csaba Raduly [rcsaba at gmail.com] Sent: 23 October 2011 18:44 To: James Molloy Cc: Paul Berube; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] build warnings On Sat, Oct 22,

Hey all, IWYU maintainer here. I wanted to make a small observation. Surprisingly, IWYU will most often *add* includes to a reasonably well-factored codebase, and this ties into Chris' comment: > Beyond that though, this seems like obvious > goodness to reduce coupling in the codebase. Just blindly removing includes will probably increase coupling, not reduce it, because it optimizes

LLVM Weekly - #211, Jan 15th 2018 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/211>. Welcome to the two hundred and eleventh issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

If your cut-n-paste is accurate, you seem to be missing a closing quote for CMAKE_CXX_LINK_FLAGS. hth... don On Jul 8, 2015 2:22 AM, "David A. Greene" <greened at obbligato.org> wrote: > greened at obbligato.org (David A. Greene) writes: > > > I looked at the instructions on the libc++ page and for Linux it > > recommends building with -stdlib=libc++ -lc++abi.

On Sat, Oct 22, 2011 at 12:24 AM, James Molloy wrote: > Hi Paul, > > That should be easy enough, because the LLVM build has no warnings in it! > > Some of us build with -Werror, and even with those of us that don't warnings are not tolerated. You're already seeing all the warnings that are coming out of the build :) So, all the "variable might be used

> On Dec 6, 2017, at 9:00 AM, mats petersson via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > In my experience, a lot of time is spent on optimizing the code (assuming it's not a "-O0" build). The numbers were actually for the debug build (-O0 -g), so for Release build they would be different (presumably lower). > Also redundant includes are largely fixed by

- We do indeed have a lot of unnecessary includes around in llvm (or pretty much any other C++ project for that matter). - I want faster builds. - The only way to reliably fight this is indeed automatic tools. - Having the right amount of includes also has documentation value and ideally let's you understand the structure of your project. - However relying on transitive includes works contrary