similar to: [LLVMdev] -Wl,native-cbe problem

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 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

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:

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

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'

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

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> There is still one unneeded LongTy in LowerInvoke.cpp - something like >>> this pseudo-diff should probably get applied. >> >> >> What does this impact? > > This causes code like > > write(2,

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

On Sat, 1 May 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > there are two issues concerning invoking optimizations: > > 1. > this document: > http://llvm.cs.uiuc.edu/docs/GettingStarted.html > is very nice, it would be good though to add in a section > > An Example Using the LLVM Tool Chain > > examples on optimization step. That's an

Hi Markus, Thanks for this interesting patch! It looks okay to me, but our C/C++ Front End guru is away right now. I would rather defer to him on this patch. He might not get to it until next week so I just wanted to let you know that there might be a bit of a delay before this patch hits mainline. I've already committed your configure changes. Reid. On Wed, 2004-12-22 at 21:42, Markus

Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> Ah ok, in that case, the CBE should be fixed. There are other cases that >> could cause long arguments to exist on 32-bit systems. If the C compiler >> takes issue with this, it would be best to tell the CBE to emit casts to C >> (long) or something. > > Actually that's the only case I stumbled over this

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 Tue, 1 Mar 2005, Jakob Praher wrote: >> If you pass '-lrt' when linking your program, it should take care of this >> for you. >> > > ah ok. so every library thet gccld can't find as a bytecode lib is added to > the shell script then. Yup. Note there are other options if you don't want to run your program in the JIT. In particular, you can use

Hi Jing, I am cc ing to LLVMdev (LLVM developer's mailing list). You get more accurate and faster responses that way. <snip> > Actually LLVM is well documented and the coding style is very friendly. We have rarely had problems since we started one month ago. Unfortunately, here comes something I am not very clear, but it is critical to our evaluation. I appreciate if you could

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 Fri, 11 Mar 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Thu, 10 Mar 2005, Andrew Lenharth wrote: >> >>> yes, so this happens on anything that uses a struct for va_list (like >>> alpha). I am currently working on fixing this. if you look at the last >>> patch to the alpha portion of llvm-gcc, you can see a quick hack to work

For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It didn't make a difference. So here are the failures for llvm-test. All diffs are against the "native" output. ===================== MultiSource/Applications/sgefa cbe failed differently from jit/llc. First cbe: 84c84 < One-Norm(A) ---------- 8.879153e+02. --- > One-Norm(A) ---------- 8.879156e+02.

Chris Lattner wrote: > On Tue, 1 Mar 2005, Jakob Praher wrote: > >>> If you pass '-lrt' when linking your program, it should take care of >>> this for you. >>> >> >> ah ok. so every library thet gccld can't find as a bytecode lib is >> added to the shell script then. > > > Yup. Note there are other options if you

Hi all, as suggested on the mailing list I have converted the updated LZO code into git, so please pull my "lzo-update" branch from git://github.com/markus-oberhumer/linux.git lzo-update You can browse the branch at https://github.com/markus-oberhumer/linux/compare/lzo-update I''d ask some official kernel maintainer for review and to push this into linux-next so that it