similar to: [LLVMdev] compile errors with demo projects Stacker and Hello

If I remember correctly, you get the following warning when you configure LLVM: configure:2087: WARNING: Unknown project (Stacker) won't be configured automatically That leads would lead me to believe that you need to run configure inside llvm/projects/Stacker (and inside llvm/projects/Hello) before you run gmake inside of them. I don't know for sure, but perhaps that might fix

I'm also getting these errors: gmake[2]: Entering directory `/usr/home/llvm/projects/Stacker' ../../Makefile.common:60: ../../Makefile.config: No such file or directory ../../Makefile.common:65: /Makefile.rules: No such file or directory gmake[2]: *** No rule to make target `/Makefile.rules'. Stop. gmake[2]: Leaving directory `/usr/home/llvm/projects/Stacker' Everything else

>I successfully build CFE frontend at FreeBSD 5.3. > > Next nighttest run show more detail information :) After last 2 nighttest runs i see stable failure result: llvm[2]: Compiling dummylib.c for Debug build (bytecode) llvm-g++: installation problem, cannot exec `gccas': No such file or directory gmake[3]: ***

Next problem detected by nighttest: LLVM build fail with errors: gmake[4]: Entering directory `/usr/home/wanderer/pkg/build/llvm/night/build/llvm/projects/Stacker/lib/runtime' llvm[4]: Compiling stacker_rt.c for Debug build (bytecode) default/bin/llvm-gcc: not found gmake[4]: *** [/usr/home/wanderer/pkg/build/llvm/night/build/llvm/projects/Stacker/lib/runtime/Debug/stacker_rt.bc] Error 1

This kind of regression is a fallout of having some code live in separate CVS modules as "projects." It would help to have someone volunteer to maintain each project, which can be as little as making sure it continues to compile or as much as supporting it with answers to questions and bug fixes. Here is the current list of projects: llvm-poolalloc llvm-java (currently unused

Sloppy me. I fixed the path for llvm-gcc but not for llvm-g++. My last patch to Makefile.rules fixes that so it should start working again. Reid. On Fri, 2004-12-24 at 05:21, Vladimir Merzliakov wrote: > >I successfully build CFE frontend at FreeBSD 5.3. > > > > Next nighttest run show more detail information :) > > After last 2 nighttest runs i see stable failure

Hello, I was wondering what happened to the "Stacker" example. The old link to it "http://llvm.org/docs/Stacker.html" is dead. Thanks, Wayne ________________ Wayne Anderson

On 2008-04-08, at 20:21, Lane Schwartz wrote: > I checked out the Stacker directory from svn, and put it in my llvm- > src/projects directory. Unfortunately, when I run make, I get the > errors below. I wondered whether the stacker code might simply be > out of date It is. The fixes are likely mechanical, but just require someone stepping up and submitting a patch. — Gordon

As a learning aid for myself and for other would be source language writers for LLVM, I have decided to write a very simple language I'm calling "Stacker". Its kinda like Forth but way, way, way simpler. Its nowhere near ANS Forth and it won't be useful for much other than demonstrating how to create a source language using LLVM. I thought I'd mention this just so everyone

Hi! In current LLVM CVS: llvm/projects/Stacker/Makefile.common.in llvm/projects/sample/Makefile.common.in llvm-java/llvm-java/Makefile.common.in have line: include $(LLVM_OBJ_ROOT)/Makefile.common that have line: include $(LLVM_OBJ_ROOT)/Makefile.config (also $(LLVM_OBJ_ROOT)/Makefile.config used in llvm-test/Makefile.config.in) and llvm/Makefile.config.in have lines: INSTALL_SH :=

LLVM build without big problems in obj dir == src dir case (for example, last night tester build) But I have problem with building CVS version LLVM in obj dir != src dir case. ======= Finished building ModuleMaker debug executable (without symbols) ======= gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/llvm/obj/examples/ModuleMaker' gmake[1]: Leaving directory

On Tue, Apr 8, 2008 at 8:00 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2008-04-08, at 20:21, Lane Schwartz wrote: > > > I checked out the Stacker directory from svn, and put it in my llvm- > > src/projects directory. Unfortunately, when I run make, I get the > > errors below. I wondered whether the stacker code might simply be > > out of

On Tue, Apr 8, 2008 at 8:25 PM, Lane Schwartz <dowobeha at gmail.com> wrote: > OK. Thanks for the info. Is there a working sample project that I could look at? > > I'm interested in tinkering around with my own custom frontend for a > toy language, and I was hoping for something I could use as a template > in getting a project set up properly. Did you try the

I am interested in analyzing the bytecode code produced for C files. By default, inlining of user and library functions (libc) is done. If I turn off inlining (-disable-inlining in gccas and gccld) then no inlining is done. I want to be able to inline user code but disallow library code to be inlined. In trying to understand the InlineSimple.cpp code, I see that library functions are

On Mon, 14 Feb 2005, Reid Spencer wrote: > Personally, I don't think LLVM projects should need much in the way of > autoconf stuff. They certainly don't need to replicate things like > install-sh and mkinstalldirs. I'd vote for taking these out of the > projects rather than making the makefiles deal with them. I think in > most cases these are just historical artifacts

Vikram S. Adve wrote: > This kind of regression is a fallout of having some code live in > separate CVS modules as "projects." It would help to have someone > volunteer to maintain each project, which can be as little as making > sure it continues to compile or as much as supporting it with answers > to questions and bug fixes. Here is the current list of projects:

On Mon, 2005-02-14 at 20:53, Chris Lattner wrote: > On Mon, 14 Feb 2005, Reid Spencer wrote: > > > Personally, I don't think LLVM projects should need much in the way of > > autoconf stuff. They certainly don't need to replicate things like > > install-sh and mkinstalldirs. I'd vote for taking these out of the > > projects rather than making the makefiles

On Thu, 21 Feb 2008, Dale Johannesen wrote: > The defined gcc interface for this is -fno-builtin. It seems not be > to be working in llvm-gcc, however. Please file a reduced testcase in bugzilla, -Chris > >> I am interested in analyzing the bytecode code produced for C files. >> By default, inlining of user and library functions (libc) is done. If >> I turn off

I tried to compile the currently checked in version of llvm-poolalloc with the curently checked in version of llvm and got the following errors: llvm[4]: Compiling Heuristic.cpp for Debug build (PIC) Heuristic.cpp: In function 'bool Wants8ByteAlignment(const llvm::Type*, unsigned int, const llvm::TargetData&)': Heuristic.cpp:77: error: 'const class llvm::TargetData' has no

Hi all, A few things. Firstly, I've got a working implementation of the X86ThisCall calling convention, but I'm unsure how to go about submitting it. (I'm not really sure how to go about creating patch files etc, but would like to contribute to the project). Also, I'm using MS Visual C++ Express, and there are a few things that stop llvm1.9 (and the current CVS release) from