similar to: [LLVMdev] sys::Program::ExecuteAndWait() caller problems

It's correct; the win32 version also expects the first arg to be the name of the program. Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: > >> On Sun, 10 Apr 2005, Markus F.X.J. Oberhumer wrote: >> >>> sys::Program::ExecuteAndWait() requires that the first element in >>> "args" should be the name of the program, but (at least) llvm-ld.cpp

--- include/llvm/System/Program.h | 8 ++++---- lib/System/Unix/Program.inc | 30 +++++++++++++++--------------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/include/llvm/System/Program.h b/include/llvm/System/Program.h index 49de7cf..14f9e9e 100644 --- a/include/llvm/System/Program.h +++ b/include/llvm/System/Program.h @@ -97,12 +97,12 @@ namespace sys { ///

[Chris asked me to bring this up on the mailing list some time ago, but I couldn't get to it. Sorry for that.] Since the beginning, I used ReST [1] for documenting llvmc, instead of plain HTML that was used historically. In my opinion, ReST is much easier to write and read (in the text editor or on terminal); it can also be used to produce PDFs, man pages or HTML that looks exactly the same

I'm building a static analysis tool on top of LLVM. It needs to take in a C++ source file and have LLVM translate it into bitcode. In other words, it basically needs to do this: llvmc hello.cpp -emit-llvm -O0 -S -g Except that instead of writing the bitcode to a file, it needs to load it into memory (presumably as an instance of Module) for further processing and analysis. So my

Hi All, I'm using LLVM/Clang 3.1 release. I first compiled llvm/clang using GCC per the instructions on the web with cmake. I then compiled libc++ per the instructions on the web. I then tried to compile llvm/clang with previously compiled clang and libc++ using "-std=c++0x -stdlib=libc++" flags. But the compilation fails at: > [ 58%] Building CXX object

On 2012-06-26 04:22, Ashok Nalkund wrote: ... >> /local/mnt/workspace/ashoknn/519_libcxx_transition/llvm/src/tools/bugpoint/ToolRunner.cpp:131:12: error: invalid operands to binary expression ('llvm::raw_ostream' and 'std::ostringstream' >> (aka 'basic_ostringstream<char>')) >> errs() << OS; >> ~~~~~~ ^ ~~ > Hi Ashok,

Folks, As of the writing of this note, the llvmc tool is enabled for build on the CVS head. I'm encouraging you to try it out, provide some feedback, and help with the issues below. llvmc is now able to correctly link a pure bytecode version of any Stacker program. This includes translation with stkrc, optimization with opt and linking with llvm-link. It is also able to find Stacker's

WikiFormatting for code documentation? :-) -scooter On Tue, Dec 9, 2008 at 7:56 AM, Mikhail Glushenkov <foldr at codedgers.com>wrote: > [Chris asked me to bring this up on the mailing list some time > ago, but I couldn't get to it. Sorry for that.] > > Since the beginning, I used ReST [1] for documenting llvmc, instead of > plain HTML that was used historically. In my

Can you compare ReST to docbook? We've talked about using docbook for a long time. What are the pros and cons of each? Thanks, Tanya On Dec 9, 2008, at 7:56 AM, Mikhail Glushenkov wrote: > [Chris asked me to bring this up on the mailing list some time > ago, but I couldn't get to it. Sorry for that.] > > Since the beginning, I used ReST [1] for documenting llvmc, instead

Hello everyone, The bugpoint is changed to escalate remote client return status 255 (per discussion - Re: [llvm-commits] [llvm] r75665 - /llvm/trunk/tools/bugpoint/ToolRunner.cpp) Please find the patch attached. -Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolRunner.diff Type: application/octet-stream Size: 4710 bytes Desc: not available URL:

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

Hi, I get this error: ------------------ ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) ToolRunner.cpp:396: error: (Each undeclared identifier is reported only once for each function it appears in.) ------------------ And the config.log shows that configure has detected that ld on my platform (Interix) doesn't support shared libraries: ------------------

Hi again Does cygwin support shared libraries. And if not, how did you port llvm on this issue? /Henrik >From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Tue, 27 Jul 2004 00:41:53 +0200 > >Hi, > >I get this error: >------------------ >ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) >ToolRunner.cpp:396:

gccld passes -shared through if it's generating a shared library, but if you're compiling a program that needs to have its symbols externally accessible, it doesn't pass -export-dynamic through to gcc for the final link. The attached patch fixes this. I've tested with a small test case I sent Chris, and with Python; both seem to work. I also fixed some inaccurate comments in

Hello everyone, Please find the patch attached. This fixes the bugpoint -remote-client and adds a helper script for a remote run. -Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolRunner.diff Type: application/octet-stream Size: 4210 bytes Desc: not available URL:

--- include/llvm/System/Program.h | 14 ++++++++++---- lib/System/Unix/Program.inc | 17 +++++++++-------- lib/System/Win32/Program.inc | 16 +++++++++------- 3 files changed, 28 insertions(+), 19 deletions(-) diff --git a/include/llvm/System/Program.h b/include/llvm/System/Program.h index 14f9e9e..05c73ac 100644 --- a/include/llvm/System/Program.h +++ b/include/llvm/System/Program.h @@

Ok guys, Here is the patch (I also had to update lib/CompilerDriver/Makefile because it tries to run llvm-config without building it!). I checked that build works and errors in llvm-config are properly detected. Could someone verify and commit it? I do not have write access to svn (how can I get one BTW?). -Yuri Gribov -------------- next part -------------- A non-text attachment was

Hi, I am trying to build my own llvmc plugin, but somehow, the llvm makefiles do not pick up the plugin in the llvmc/plugins directory anymore in a recent (r129445) svn checkout. According to the tutorial (http://llvm.org/docs/CompilerDriverTutorial.html): $ cd tools/llvmc $ cp -r example/Simple plugins/Simple $ make LLVMC_BASED_DRIVER_NAME=mygcc LLVMC_BUILTIN_PLUGINS=Simple does not build

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/23 <Sanjiv.Gupta at microchip.com> > >>> BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm >>> working on a fix. >>> >> Hi Mikhail, >> Did you get a chance to fix this. I still get errors while building examples. >> >> > > This issue

Thanks Viktor. + std::cout << "<run locally>" << std::flush; This should use std::cerr and make sure it is wrapped inside the DEBUG macro. Also, we don't want RemoteRunSafely.sh to be under utils/bugpoint. Can you move it to test-suite? Are you planning to change the llvm test suite makefile to make use of RemoteRunSafely.sh? Thanks, Evan On Jul 7,