similar to: [LLVMdev] Need help with bugpoint for codegen problem

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 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, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote: > Ok, after pasting the output from "gccas -debug-pass=Arguments > </dev/null -o - >/dev/null" I get the following: > > bugpoint -verify -lowersetjmp -funcresolve -raiseallocs -simplifycfg > -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine > -simplifycfg -prune-eh

On Mon, 11 Jul 2005, Long Fei wrote: > > This didn't work as I tried with 197.parser. it works without > "-Wl,-disable-opt" switch though. > > [197.parser]$ llvm-gcc analyze-linkage.c and.c build-disjuncts.c > extract-links.c fast-match.c idiom.c main.c massage.c parse.c post-process.c > print.c prune.c read-dict.c utilities.c xalloc.c word-file.c

This didn't work as I tried with 197.parser. it works without "-Wl,-disable-opt" switch though. [197.parser]$ llvm-gcc analyze-linkage.c and.c build-disjuncts.c extract-links.c fast-match.c idiom.c main.c massage.c parse.c post-process.c print.c prune.c read-dict.c utilities.c xalloc.c word-file.c strncasecmp.c -Wa,-disable-opt -Wl,-disable-opt -lm -o llvm_parser [197.parser]$

On Wed, 20 Apr 2005, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: >> 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 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, 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 >

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 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 Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: > On May 5, Misha Brukman wrote: > > To the best of my knowledge, this has not been done and no one has > > announced their intent to work on it, so if you are interested, > > you'd be more than welcome to do so. > > My C++ knowledge is completely non-existant, but so far I've had a >

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

On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >

Hi LLVMers, Sorry for the delay, this status update should have been out a couple weeks ago. Things have been absolutely crazy here. :) May Status Update ----------------- Overall, since the LLVM 1.2 release, we've fixed several LLVM optimizations to produce better code (most have fallen into the "stop doing stupid things" category) and implemented some new optimizations. There

On Fri, 22 Apr 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Fri, 22 Apr 2005, Markus F.X.J. Oberhumer wrote: >>> many thanks once more for your quick fix for this issue. Actually the >>> current CVS version is the first version since llvm-1.3 which does not >>> miscompile the UCL library, so this is a definitive improvement :-). And

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

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.

On Fri, Feb 18, 2005 at 11:30:45AM -0600, Feng Chen wrote: > However, although the configuration and installation process doesn't > report any error/warning, the llvmc cannot work. It just says: > Unexpected unknown exception occurred :( > > Do you have any clue about that? Have you compiled and installed llvm-gcc/llvm-g++? llvmc is not a compiler, it's just a compiler