similar to: [LLVMdev] -inline odd behavior

On Fri, Feb 10, 2012 at 2:38 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I have some code that has one function and if I use the-inline on it then > these opts eliminate the entire function (which is the entire file). > > Bugpoint produces bugpoint-reduced-simplified.bc, but when I then run "opt > bugpoint-reduced-simplified.bc -inline" I get nothing, file get

Seems like bad behavior to just decide to delete the function, no? Why not just ignore it then and output the input? On Fri, Feb 10, 2012 at 2:43 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Feb 10, 2012 at 2:38 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I have some code that has one function and if I use the-inline on it then > > these opts

Yes, that makes sense but not if it isn't doing anything with it. If it doesn't inline it then it shouldn't be modifying it, or at least that's what makes sense to me. If part of it's job is to delete functions that were created "dead" by some other opt, then shouldn't that opt be deleting the functions it makes dead? I guess I don't see the point in deleting

On Fri, Feb 10, 2012 at 2:47 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Seems like bad behavior to just decide to delete the function, no? Why not > just ignore it then and output the input? Deleting dead functions is part of the functionality of -inline. -Eli > > > On Fri, Feb 10, 2012 at 2:43 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: >>

Ok, I have attached the bugpoint-reduced-blocks.ll test case, just fyi. Thanks, I'm just curious at this point. On Wed, Feb 8, 2012 at 11:56 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Wed, Feb 8, 2012 at 10:09 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Unfortunately, I cannot provide the exact code, but I will attempt to > look > > for the

On Wed, Feb 8, 2012 at 10:09 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Unfortunately, I cannot provide the exact code, but I will attempt to look > for the reason and post a test case. Okay... note that bugpoint is very good at reducing testcases which crash. -Eli > > > On Tue, Feb 7, 2012 at 6:04 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>

Unfortunately, I cannot provide the exact code, but I will attempt to look for the reason and post a test case. On Tue, Feb 7, 2012 at 6:04 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Feb 7, 2012 at 5:52 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > opt: > /home/ryan/llvm/llvm_core/llvm-3.0/include/llvm/Support/Casting.h:194: > > typename

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

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

On Mar 26, 2014, at 6:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 3/26/2014 11:39 AM, İsmail Dönmez wrote: >> >> make check-all but yes make check would suffice. Thanks! > > I see two reported failures: > > > FAIL: LLVM :: BugPoint/compile-custom.ll (459 of 9992) > ******************** TEST 'LLVM ::

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

Hi, I didn't get a clear idea what to do whit this problem: OptimizerDriver.cpp seems to be unix platform specific. However, I'm compiling this on MinGW. Shouldn't this be moved to lib/System/<platform>? Any suggestions? -------------------------- c:/Projects/src/llvm/tools/bugpoint/OptimizerDriver.cpp:28:22: sys/wait.h: No such file or directory

On Wed, Oct 31, 2012 at 04:43:42PM -0700, Eli Friedman wrote: > On Wed, Oct 31, 2012 at 4:33 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > > On Wed, Oct 31, 2012 at 03:53:50PM -0700, Eli Friedman wrote: > >> On Wed, Oct 31, 2012 at 8:43 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > >> > While testing llvm/polly svn on

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 `memcpy' bugpoint-test-program.bc.cbe.c: In function `main':

Thank you for this information. If so, is there any way to grasp which kinda data throw in and out in LLVM as shown in such a way in gdb? Thanks, Seung Jae Lee ---- Original message ---- >Date: Tue, 20 Feb 2007 23:54:04 -0600 >From: "John T. Criswell" <criswell at cs.uiuc.edu> >Subject: Re: [LLVMdev] bugpoint usage >To: LLVM Developers Mailing List <llvmdev at

On Jul 8, 2009, at 1:52 PM, Viktor Kutuzov wrote: >> bugpoint should be a standalone tool. It should not require a >> separate >> script to handle remote execution. Why is the script needed? > > Bugpoint is a standalone too and does not require any separate script. > The script is a helper for using ssh as a remote client. Ok. > > Bugpoint should not be aware

On Wed, Oct 31, 2012 at 5:01 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > On Wed, Oct 31, 2012 at 04:43:42PM -0700, Eli Friedman wrote: >> On Wed, Oct 31, 2012 at 4:33 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: >> > On Wed, Oct 31, 2012 at 03:53:50PM -0700, Eli Friedman wrote: >> >> On Wed, Oct 31, 2012 at 8:43 AM, Jack Howarth

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 everyone, I want to test the passes in llvm, and I got some passes sequences that caused the crash of opt. Although I can use bugpoint to narrow down the source of problems, I can only get some reduced and simplified IR and passes to reproduce the problem. My question is how to get the reduced IR of the original IR file to reproduce the problem. For example, "opt a.bc -a -b -c -d (where

> bugpoint should be a standalone tool. It should not require a separate > script to handle remote execution. Why is the script needed? Bugpoint is a standalone too and does not require any separate script. The script is a helper for using ssh as a remote client. Bugpoint should not be aware of any details how the test program will be delivered to a remote target, get executed there, and