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

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 and gccld.cpp > fail to do so, thereby effectively swallowing the first parameter. > This is the reason that -native-cbe has not working for some time - actually > I wonder why no

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

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

On Mon, Aug 01, 2005 at 05:13:15PM -0500, Nicholas Riley wrote: > The attached patch fixes this. ...but had tabs in it. Misha kindly reminded me off-list that this was bad. Try this one instead. -- Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley> -------------- next part -------------- Index: tools/gccld/GenerateCode.cpp

I will definately look into this tonight and see if it is a problem with my recent patch. On Wednesday 02 March 2005 3:39 am, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > >>Follow up: After removing the dangling symlink the problem now looks: > >> > >>-march=c((anonymous

On Fri, Apr 22, 2005 at 03:13:44AM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Fri, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote: > >>[...] > >>bugpoint: Unknown command line argument '-instcombine-load-vn'. Try: > >>'bugpoint --help' > > > >You need a space between -instcombine and

Adam, Looks like you have your first issue with the gccld patch. Could you please look into this for us? Markus seems to have detected a situation where -native-cbe is acting like -native ... On Wed, 2005-03-02 at 00:39, Markus F.X.J. Oberhumer wrote: > Short update: -native-cbe is currently broken as gccld/llc seems to generate > assembler code instead of C. To easy debugging of such

On Fri, Apr 22, 2005 at 01:46:53AM +0200, Markus F.X.J. Oberhumer wrote: > Debugging code generator problem! > <cbe><gcc><program>Warning: While generating reference output, program > exited with > non-zero exit code. This will NOT be treated as a failure. > > *** The C backend cannot match the reference diff, but it is used as the > 'known good'

On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > Follow up: After removing the dangling symlink the problem now looks: > > -march=c((anonymous namespace)::PrintStackTrace()+0x1e)[0x847a17e] > -fno-strict-aliasing: example.out.cbe.c: No such file or directory > gccld: example.out.cbe.c: Can't destroy file: > make: *** [example.out] Error 1 > At a minimum that

The LLVM 1.4 Release is now out! Get it here: http://llvm.cs.uiuc.edu/releases/ or read about it here: http://llvm.cs.uiuc.edu/releases/1.4/docs/ReleaseNotes.html#whatsnew This release features a huge assortment of improvements in functionality, generated code quality, and compile times. Thanks to everyone who has helped make this release the best one yet. In addition to the changes

On Wed, 2 Mar 2005, Markus F.X.J. Oberhumer wrote: > When running the current CVS version on an AMD64 (targeted at 64-bits) I hit > the following when trying to link with -Wl,native-cbe: > > march=c((anonymous namespace)::PrintStackTrace()+0x1e)[0x847a17e] > /lib/libc.so.6(abort+0xcc)[0x556abbbc] > -march=c[0x8261958] > [0x8afe738] > gccld: /usr/lib/../lib64/X11:

Hi, Can anyone tell me why CopyFile is the only undefined reference from Path.cpp? --------------- llvm[2]: Linking Debug executable gccld c:/projects/build/MinGW/llvm-1-1/tools/gccld/Debug/gccld.o(.text+0x439): In function `Z15EmitShellScriptPPc': c:/projects/src/llvm-1/llvm/tools/gccld/gccld.cpp:127: undefined reference to `llvm::sys::CopyFile(llvm::sys::Path const&, llvm::sys::Path

Get the latest version. I committed a fix to Path.cpp last night. It wasn't being defined in the sys:: namespace which is why its undefined. Reid. On Thu, 2004-12-23 at 10:44, Henrik Bach wrote: > Hi, > > Can anyone tell me why CopyFile is the only undefined reference from > Path.cpp? > > --------------- > llvm[2]: Linking Debug executable gccld >

On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer wrote: > While trying to hunt down a codegen bug (not yet found) ... Have you considered using bugpoint for your codegen debugging needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > I've collected some small patches you might find useful. Sweet! > Please review and apply as you see fit. I've

On Sat, 16 Apr 2005, Markus F.X.J. Oberhumer wrote: > I have troubles with a freshly built CVS toolchain when linking a C++ program > with -Wl,-native: > > gccld: error: Cannot link in module > '/media/sda3/opt/cc-i386-linux/llvm/llvm-1.4.20050416-i386-linux/cfrontend/bin/../lib/gcc/i386-pc-linux-gnu/3.4-llvm/../../../libstdc++.a(allocator-inst.o)': > Linking globals

On Fri, Apr 22, 2005 at 02:14:23AM +0200, Markus F.X.J. Oberhumer wrote: > Hmm - is there some option so that bugpoint automatically runs all the > passes that are normally run by gccas and gccld ? Nope, that's not built into bugpoint, hence the procedures in the document. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

On Fri, 22 Apr 2005, Markus F.X.J. Oberhumer wrote: > I've finally got it working! The key point was to pass all bytecode > objects individually to bugpoint, and not to use the pre-linked bytecode from > gccld. nice! > After running for some time bugpoints exits saying: > > *** The following functions are being miscompiled: ucl_alloc main >

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

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 Trevor, > 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 behind the scenes it's actually llvm-gcc that is generating the bitcode. > Except that instead of writing the bitcode to a file, it