search for: clangtools

Hi Daniel, I would like to go deeper with CommandLine and I was asking if you could help me again. Look, following the same example you put in the last message: ./prog <option1> | ( <option2> --arg1 --arg2) | ( <option3> --arg1 ) What I really really want is the same except I don't want the "--" prefix is present in any of the arguments. ./prog <option1>

On 10 May 2013 09:44, Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es> wrote: > Hi Daniel, > > I would like to go deeper with CommandLine and I was asking if you could > help me again. > > Look, following the same example you put in the last message: > > ./prog <option1> | ( <option2> --arg1 --arg2) | ( <option3> --arg1 ) > > What I

Hi Daniel, Thanks for your answer. > I am considering fixing the bug in the LLVM CommandLine library but is > going to be a long time before I can look at it. So don't wait for me > to do that. > Ok, ok, but, if you end up fixing this, please keep me post. > If you are really desperate to have the command line options in the > way you want they you may need to implement

On Wed, Feb 27, 2013 at 4:32 PM, Dmitry Mikushin <dmitry at kernelgen.org> wrote: > Hi Anton, > > I think it would be worth to remove this signature in the bottom line: > > Last modified: $Date: 2009/12/16 09:03:23 $ > > Otherwise, new people may think this page is long time abandoned :) It indicates that it *is* long-abandoned! We need to start actively adding to it.

> On Nov 15, 2018, at 3:34 AM, Whisperity <whisperity at gmail.com> wrote: > > I am really not sure if adding real file system functionality strictly into the VFS is a good approach. This "ExternalFileSystem" thing sounds weird to me. The `ExternalFileSystem` was an attempt to provide a more limited interface while exposing the "external" path in a way that

I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support. (The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists) https://reviews.llvm.org/D54277 proposed adding a function to VirtualFileSystem to get the underlying "real file" path from a VFS path. LLDB is starting to use VFS for some filesystem

While building llvm & clang & libs by giving some optimization options to the building compiler, the following error happened: I think it is related to the passed -DCLS=64, because in file clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411 an enum member has the same name (CLS), so it does a macro-substitution with the passed value of CLS, ie. with 64, but which of course then breakes

Hello everyone, 9.0.0-rc2 was tagged yesterday from the release_90 branch at r368683. In the Git monorepo it's available as the llvmorg-9.0.0-rc2 tag. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc2 Binaries will be added as they become available. The tag went in roughly one week behind schedule (see "Upcoming Releases" at https://llvm.org), but

On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote: > We're looking more at doing some serious hacking on LLD, and I'd like to avoid doing lots of work in the codebase only to change the style around later. > > My understanding was that LLD was always intended to be a fully integrated LLVM project much like Clang, with a shared coding standard to go with the shared support

Hello, I have tried a lot fix this error but am not able to can you please find me a solution am trying to compile the SAFECode in Cygwin Environment to work for windows. used make -j4 command to make the files in cygwin i have got this error make[5]: Leaving directory '/home/uidr7475/Work/LLVM_OBJ/projects/safecode/tools/clang/include' /usr/bin/cp: cannot stat

Greetings folks, We're looking more at doing some serious hacking on LLD, and I'd like to avoid doing lots of work in the codebase only to change the style around later. My understanding was that LLD was always intended to be a fully integrated LLVM project much like Clang, with a shared coding standard to go with the shared support libraries. Can we start that migration? I'm really

...developed initially to support the existing conventions in LLVM and Clang, and it would be a large (and of questionable utility) effort to add support for another convention as well. In essence, the desire for tools *also* advocates for the projects being consistent. [1] http://clang.llvm.org/docs/ClangTools.html#clang-format But none of this argues that the LLVM style is The Right Style. If there are ways to improve the coding conventions with LLVM and Clang, we should absolutely do that. The projects remain small enough that if you can show a convention which is superior, we can easily adopt it for...

Dear Clang/LLVM community! We (a group of 3 highly motivated CS grad students) are taking a class about compilers and optimizations. This class offers the option of doing a implementation project (instead of reading/writing x papers) for its main part. Of course hacking is much more fun than ... ;) So my question is do you know of any open points, compiler passes, optimizations in the LLVM /

> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,

I've successfully used Peter's patches to get past those relocation errors. On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Yes it should cover the following relocations: R_ARM_CALL (ARM BL/BLX) R_ARM_JUMP24 (ARM B) R_ARM_THM_CALL (Thumb BL/BLX)

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

Trying to run a self host "ninja check-clang" with ASan enabled I hit a /lot/ of errors like this (strangely I hit none of these in check-llvm, only in check-clang): Any ideas? ==10525==ERROR: AddressSanitizer failed to deallocate 0x10800 (67584) bytes at address 0x631000014800 ==10525==AddressSanitizer CHECK failed:

I wish there was something like the line in config.log that would show the CMake command, but instead I can at least show you the CMakeCache files for my release build and asan build (attached to this email). No lld, so far as I know - believe I'm using gold at the moment for both builds. Did just reproduce this with a clean release build and a clean asanified build from that. Same errors. I