similar to: Stop bugpoint from removing operand of metadata.

Hi Tim, Thanks for the explanation. The above code snippets is actually extracted by bugpoint from MultiSource/Applications/ALAC/encode/alacconvert-encode.test. I get a different result if I cast the pointer to int and mask away the lower two bits and cast the int back to pointer. While casting pointer to int and back to pointer do not cause any problem. Thanks Hongbin On Fri, Dec 16, 2016 at

Hi Hongbin, On 16 December 2016 at 12:22, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Thanks for the explanation. The above code snippets is actually extracted by > bugpoint from MultiSource/Applications/ALAC/encode/alacconvert-encode.test. > I get a different result if I cast the pointer to int and mask away the > lower two bits and cast the int back to pointer. While

Hi Hongbin, On 16 December 2016 at 11:57, Hongbin Zheng via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We have an "align 4" in the StoreInst. Does this mean > 1) the address 'A' should be aligned to 4 bytes? > 2) the lower 2 bits of 'A' should be always 0? Yes, these are both the same. It means the compiler will assume those facts when reasoning about

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

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

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

Hello. Can I use debugging options such as 'step', 'next'(in gdb) also in LLVM bugpoint? Thank you.

Hi Chen, On Jul 8, 2011, at 11:56 AM, kobe James wrote: > Hi All, > > I hope to get some information about functions in a bitcode file. Say, if we have a function foo(), and the bitcode file is generated by a single source file, then I want to get the line number foo() locates in that source file. > If the bitcode file is linked by multiple bitcode files, is it possible to also get

I have a failing test and bugpoint would be the perfect tool to help narrow it down. llc is the failing tool. It fails with one set of options and passes with another. I was hoping to use bugpoint like this: bugpoint -safe-llc -run-llc <testcase> -tool-args <failing args> -safe-tool-args <passing args> Unfortunately, this doesn't seem to be possible. According to the

I would like to use bugpoint to debug some of my passes. I have read the documentation, but I don't completely understand it. I have a bitcode file X.bc that I transform using the following commands: opt -mypass1 -f -o X.1.bc X.bc // transform with mypass1 llvm-link -f -o X.2.bc X.1.bc support.bc // link with support.bc opt -mypass2 -f -o X.3.bc X.2.bc // transform with mypass2 After

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

I'm starting work on getting bugpoint working with remote execution for arm. Is anyone else working on this? David

This is my first time using bugpoint. I'm getting the following error: /home/rkotler/llvmw/install/bin/bugpoint -run-llc casts.bc --tool-args -target mips-linux-gnu -mcpu=mips16 -mips16-constant-islands Read input file : 'casts.bc' *** All input ok Initializing execution environment: Found llc: /home/rkotler/llvmw/install/bin/llc Sorry, I can't automatically select a

Hello everyone, Please find the patch attached. This fixes the bugpoint -remote-client and adds a helper script for a remote run. -Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: ToolRunner.diff Type: application/octet-stream Size: 4210 bytes Desc: not available URL:

Hi all, I've been running into what appears to be an optimization bug in llvm, while compiling the latest ruby 1.9.3 with the latest llvm/clang 2.9 version. From hands on experimentation I do know that the gvn pass for the "vm.c" compilation is the culprit of the miscompilation (clang -O2/-O3 options produce the miscompilation, however -O1 is fine!). I've also tried to

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 Dec 6, 2010, at 2:18 AM, Ryan M. Lefever wrote: > > llc X.3.bc arg1 arg2 > > That llc command is currently seg faulting because of a bug in one of my > passes or in support.bc. Can I use bugpoint to find a smaller version of > X.bc that produces the same problem? Specifically how would I call > bugpoint to do that? bugpoint X.3.bc -run-llc -tool-args arg1 arg2 /jakob

----- Original Message ----- > From: "reed kotler" <rkotler at mips.com> > To: LLVMdev at cs.uiuc.edu > Sent: Friday, November 22, 2013 8:40:24 PM > Subject: [LLVMdev] bugpoint question > > This is my first time using bugpoint. I'm getting the following > error: > > /home/rkotler/llvmw/install/bin/bugpoint -run-llc casts.bc > --tool-args >

Thanks Viktor. + std::cout << "<run locally>" << std::flush; This should use std::cerr and make sure it is wrapped inside the DEBUG macro. Also, we don't want RemoteRunSafely.sh to be under utils/bugpoint. Can you move it to test-suite? Are you planning to change the llvm test suite makefile to make use of RemoteRunSafely.sh? Thanks, Evan On Jul 7,

Hi, when reporting http://llvm.org/bugs/show_bug.cgi?id=5104 I spent quite a while trying to figure out what passes are used by "-O1" so that I could give this list to bugpoint. It turns out -debug-pass=Arguments is mentioned in docs/HowToSubmitABug.html but under a chapter titled "Compile-time optimization bugs" which I naively ignored since my bug was not a compile-time