similar to: [LLVMdev] RFC: test/BugPoint/misopt-basictest.ll

On Feb 26, 2009, at 1:40 AMPST, Bill Wendling wrote: > On Feb 25, 2009, at 6:01 PM, Dale Johannesen wrote: > >> On Feb 25, 2009, at 4:59 PMPST, Bill Wendling wrote: >> >>> I'm running into a problem where I need to have the "gcc" that's >>> executed by "bugpoint" take certain arguments that aren't applicable >>> to

On Feb 25, 2009, at 6:01 PM, Dale Johannesen wrote: > On Feb 25, 2009, at 4:59 PMPST, Bill Wendling wrote: > >> I'm running into a problem where I need to have the "gcc" that's >> executed by "bugpoint" take certain arguments that aren't applicable >> to "llc". So, I came up with this patch, that adds a new flag >>

Hi all, while writing a testcase thate needed to do a grep containg {, I found that the DejaGNU test framework didn't handle those very well. It's a bit of a fuss to escape accolades properly, but most of all the framework seemed to silently ignore errors in the escaping (and just not run the command then). See [1]. Fixing the framework resulted in 80 of the tests failing. I spent the

I'm running into a problem where I need to have the "gcc" that's executed by "bugpoint" take certain arguments that aren't applicable to "llc". So, I came up with this patch, that adds a new flag "-gcc-tool-args". It's similar to "-tool-args" but passes the command line arguments to gcc instead of to llc. Comments? -bw

On Feb 25, 2009, at 4:59 PMPST, Bill Wendling wrote: > I'm running into a problem where I need to have the "gcc" that's > executed by "bugpoint" take certain arguments that aren't applicable > to "llc". So, I came up with this patch, that adds a new flag > "-gcc-tool-args". It's similar to "-tool-args" but passes the

On 8/29/07, Bill Wendling <isanbard at gmail.com> wrote: > On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > > Hello, Bill > > > > > It may be my lack of understanding, but it appears that having -- > > > enable-eh set during compilation of llvm-gcc is causing extra files > > > to be compiled. > > Oh, no. They are always

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 >

I've made quite a bit of progress getting bugpoint to work with our (non-gcc) tools. In fact I caught the alignment bug I recently posted about using it. But it's not there yet. In particular, I am seeing this scenario a lot (comments in brackets): *** Found miscompiling pass: -instcombine Emitted bitcode to 'bugpoint-passinput.bc' [ Good! This is progress! ] *** You can

Hi all, Is anyone else seeing tests in the Multisource/Applications directory failing with something looking like this: /Users/wendling/llvm/llvm.obj/Debug/bin/gccld -L/Users/wendling/llvm/ llvm-gcc4.install/lib/gcc/powerpc-apple-darwin8.8.0/3.4-llvm -L/ Users/wendling/llvm/llvm-gcc4.install/lib Output/siod.linked.bc -lc -lpthread -lltdl -lm -o Output/siod.llvm gccld: warning: Cannot

Thank you so much for this info. That's exactly what I want. But, I'm still not sure about using -g. Let me imagine I am modifying x86 assembly instructions and trying to test it with 'hello.c' to check out the assembly is properly emitted. I should type "$ llvm-gcc hello.c -o hello" to have the bytecode of 'hello.c'. And then I can have an x86 assembly mnemonics

Chandler Carruth wrote: > On Tue, Jan 24, 2012 at 12:02 PM, Bill Wendling <wendling at apple.com > <mailto:wendling at apple.com>> wrote: > > On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote: > > > On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling > <wendling at apple.com <mailto:wendling at apple.com>> wrote: > > Hello, >

--- tools/bugpoint/bugpoint.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I came across this while running bugpoint --help, hope you don't mind the git patch output :) diff --git a/tools/bugpoint/bugpoint.cpp b/tools/bugpoint/bugpoint.cpp index 2364675..587077e 100644 --- a/tools/bugpoint/bugpoint.cpp +++ b/tools/bugpoint/bugpoint.cpp @@ -67,7 +67,7 @@ int main(int argc,

On Jan 24, 2012, at 9:11 PM, Nick Lewycky wrote: > Yeah, I can't think of any use for something that would pull out NamedMDNodes for no reason. That said, if you want this to work, please audit the module cloner at the very least (it should copy the NamedMDNodes). > > But what would you do with llvm-extract? llvm-extract already copies over named metadata. > Should it keep a

Hi again, On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: Running /Users/wendling/llvm/llvm.src/test/CodeGen/X86/dg.exp ... FAIL: /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- TailMergingBug.ll for PR1909 Failed with exit(1) at line 1 while running: llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/ X86/2008-02-18-TailMergingBug.ll | llc -march=x86

On Wednesday 16 July 2008 10:31, David Greene wrote: > On Wednesday 16 July 2008 10:12, David Greene wrote: > > I'm having some trouble using bugpoint with newer version of gcc > > (bugpoint debug output below). > > I was using gcc 4.1.2. When I try 3.2.3 I get: > > bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in > function

I'm having some trouble using bugpoint with newer version of gcc (bugpoint debug output below). I looked into the "conflicting type for malloc" problem and it doesn't seem easy to solve due to the unknown size of size_t (see LowerAllocations.cpp). The "void main()" problem is probably a result of this test being converted from Fortran. I'll have to dig into

Attached is a patch that fixes it for the cmake build. I'm not positive this is the right place to put it and I really have no idea where the check should go when using the autotools. -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-rdynamic.patch Type: application/octet-stream Size: 663 bytes Desc: not available URL:

Hi, I am trying to reduce what I believe to be a miscompilation bug. Running lli on my bitcode file causes a segmentation fault. However, running bugpoint as bugpoint file.bc gives me the following errors, /tmp/ccAdmNqH.o: In function `_ZL17bus_error_handleriP7siginfoPv': bugpoint-test-program.bc-Vega5s.cbe.c:(.text+0x1b4e1): undefined reference to `std::cerr' /tmp/ccAdmNqH.o: In

Sorry to ask about a documented use of bugpoint, but I am having trouble understanding what to do. I would like to be able to use bugpoint to simplify test cases, when the symptom is a run time difference in the testprogram behavior. That looks like what is described in the documentation as "miscompilation or perhaps code generation problems". There are examples in the LLVM doc showing

While running the llvm tests, I get several error messages like these: [1/1] Running the LLVM regression tests FAILED: cd /home/steve/llvm-build/test && /usr/local/bin/python /home/steve/llvm/utils/lit/lit.py --param build_config=. --param build_mode=Release -sv --param llvm_site_config=/home/steve/llvm-build/test/lit.site.cfg --param