similar to: [LLVMdev] Linkage Types again!

> That's essentially what I did to get it to work but instead of > appending, I just opted for LinkOnce. Sounds ok. > > I don't quite understand why you need an appending global to do this, if you > > can only have one main. I would just set it to the correct initializer in the > > module that has main, and leave it external everywhere else. > > Its

While it is great that LLVM has an IR Verifier, its a little troublesome to use because it separates the point of detection from the source of the problem. That is, the verifier gets run on a module or function after its been built. By that point, the compiler's state has moved past the point at which the error was placed into the module or function. Trying to track down the source of the

Reid Spencer wrote: > On Mon, 2006-02-27 at 20:43 -0800, Wink Saville wrote: > >>> Try passing "-L/opt/llvm-1.6/llvm-gcc/lib/ -lcrtend" to llvm-ld. >>> >> This didn't work for me: >> llvm-ld -o t1.app t1.bc t1.a -L/opt/llvm-1.6/llvm-gcc/lib/ -lcrtend.a >> >> I get two warning's about library 'crtend' missing

On Mon, 2006-02-27 at 20:43 -0800, Wink Saville wrote: > > Try passing "-L/opt/llvm-1.6/llvm-gcc/lib/ -lcrtend" to llvm-ld. > This didn't work for me: > llvm-ld -o t1.app t1.bc t1.a -L/opt/llvm-1.6/llvm-gcc/lib/ -lcrtend.a > > I get two warning's about library 'crtend' missing > You didn't get the instructions quite right. The option is

Having recently become interested in llvm I've read a lot of documentation on your website. Considering that a 2.5 release is due out soon, I'm guessing there will be additional readers and writers focusing on the docs. Would feedback in this area be welcome? Simple misspellings of words on various pages like Subvresion, producess, performsn, instructiosn, catagory, and mis-behaving seem

Chris Lattner wrote: > On Sun, 26 Feb 2006, Wink Saville wrote: >> I then do the following in my makefile: >> >> llvm-gcc -c t1.c -o t1.bc >> llvm-gcc -c t1sub1.c -o t1sub1.bc >> llvm-gcc -c t1sub2.c -o t1sub2.bc >> llvm-ar r t1.a t1sub1.bc t1sub2.bc >> llvm-ar: creating t1.a >> llvm-ld -o t1.app t1.bc t1.a /opt/llvm-1.6/llvm-gcc/lib/libcrtend.a

Before I file a bug, I thought I'd check to make sure something hasn't changed. Stacker used to work in 1.2, now it fails on six tests. All six tests pertain to use of the SetLT, SetGT, SetLE, and SetGE SetCondInst. In my test programs they all fail, regardless of the values. The *only* thing I've done to Stacker is to change the base type involved in the comparison from int to long.

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

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Hello, I'm trying to get the demo script to run llvm2cpp so that people can get familiar with the LLVM C++ API through the online demo. However, it seems that the path used doesn't include llvm2cpp (not updated in a while?). The demo script currently uses these paths on Zion: /home/vadve/criswell/box/x86/llvm-gcc/bin/ /home/vadve/gaeke/llvm/Release/bin /home/vadve/gaeke/bin

It's already messed with, but there's no harm. If someone turns on the llvm2cpp option, then they get an error message at the bottom of the output page. All other output is normal. So, there's no harm in it. If/when llvm2cpp becomes available on Zion, people then the llvm2cpp output will appear. Note that llvm2cpp is a 1.8 release feature. My change was to help people learning LLVM

> I'm trying to get the demo script to run llvm2cpp so that people can get > familiar with the LLVM C++ API through the online demo. However, it > seems that the path used doesn't include llvm2cpp (not updated in a > while?). The demo script currently uses these paths on Zion: I can look into this, but I would strongly suggest not messing with the demo script until 2-3

Hi, I get this error: --------------- configure: configuring in projects/Stacker configure: running /bin/sh '/C/projects/src/llvm-2/llvm/projects/Stacker/configure' --prefix=/C/LLVM/tools/ '--prefix=/C/LLVM/tools/' 'CPPFLAGS=-D__MINGW -DLLVM_ON_WIN32=1' --cache-file=/dev/null --srcdir=/C/projects/src/llvm-2/llvm/projects/Stacker configure: error: invalid variable

All, I'm finding the current layout a bit frustrating, not to mention that it breaks all the documentation. We currently have modules laid out like this: llvm/trunk/... llvm/branches/... llvm/tags/... stacker/trunk/... stacker/branches/... stacker/tags/... and similarly for all the other modules (test-suite, java, poolalloc, etc.). Unfortunately, this "standard"

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

Reid, Click on any of these logs and you'll see the same asm parsing issues. It's been going on for much of the week. http://llvm.org/nightlytest/machines/2006-12-29_05:40:12-Build-Log.txt http://llvm.org/nightlytest/machines/2006-12-29_05:40:12-Build-Log.txt llvm[4]: Compiling stacker_rt.ll to stacker_rt.bc for Release build (bytecode)

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 Fri, 2003-12-19 at 15:32, Chris Lattner wrote: > This is intentionally not part of the LLVM type-system, because it is > redundant. If you compile a C program that uses a union, for example, the > C front-end will turn it into a type (often a structure) that contains > only one of the element types (usually the largest one, perhaps modified > to have the correct alignment).