similar to: [LLVMdev] bugpoint with other tools

Hi Dave, > It seems that bugpoint (and llvmc2, etc.) is hard-wired to use gcc to do > assembling and linking. I want to bugpoint-reduce a testcase that came > from Fortran and so I need to invoke our compiler to do at least the linking > step to get our Fortran libraries. you can always cheat and have gcc be a symlink to your compiler. Ciao, Duncan.

Hi, LLI now supports -load but bugpoint LLI:ExecuteProgram() still assumes that it doesn't. The attached patch makes bugpoint pass -load arguments to LLI and lets one to use bugpoint with programs that depend on native shared libraries. best regargs, Timo Lindfors -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-bugpoint-load1.patch Type: text/x-diff

> I will investigate. I'm in the middle of it as well. Best regards, Viktor ----- Original Message ----- From: "David Goodwin" <david_goodwin at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, July 10, 2009 2:43 PM Subject: Re: [LLVMdev] Heads up! Working on bugpoint >I just checked in my changes to bugpoint and

I just checked in my changes to bugpoint and Makefile.programs in the test suite. These changes shouldn't conflict with yours. revision 75292 revision 75293 bugpoint now works for remote ARM if you run it directly from the command line. It doesn't work correctly when invoked from the test makefile because envvar PWD is being set to /bin/pwd and so causing GCC::ExecuteProgram to

Hi Prakash, Unfortunately it looks like you need to do quite a bit of investigation into this. However, I hope I can provide some useful tips. 1. In general, lli and llc generate exact the same code except lli default to static codegen while llc defaults to dynamic-no-pic codegen. So try passing -relocation-model=dynamic-no-pic to lli. If this works, that means there are issues with

Hi Eli, Thanks for the reply. I tried with -Xlinker="-ldl ". However it does not seem to make a difference. It seems that when bugpoint is run with --run-jit, the linker args are not passed to gcc (from tools/bugpoint/ExecutionDriver.cpp) : if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) RetVal =

Hello, David > bugpoint now works for remote ARM if you run it directly from the > command line. It doesn't work correctly when invoked from the test > makefile because envvar PWD is being set to /bin/pwd and so causing > GCC::ExecuteProgram to do the wrong thing. I'm not sure what is going > on with that, perhaps something in the makefile hierarchy is setting > PWD to

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Justin > Bogner via llvm-dev > Sent: Monday, July 22, 2019 11:44 > To: Jay Foad via llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Fwd: bugpoint can't automatically select a safe > interpreter! > > Bugpoint's user interface is notoriously

On 6/11/19 12:25 PM, Philip Reames via llvm-dev wrote: At the moment, bugpoint has three major use cases: crash reduction, miscompile reduction, and mutation fuzzing. Out of these, a huge proportion of the interface complexity comes from the miscompile handling. I generally agree with removing the auto-detection logic. I've found it to be extraordinarily error prone and confusing.

Hi, I have a program that runs when statically compiled using llc and gcc but crashes with a segmentation fault when run with lli. I am trying to debug it with bugpoint and the initial part of bugpoint seems to be suggesting that I am somehow missing the linking with the libraries having dlsym/dlopen although I am passing it to lli : *$ bugpoint -run-jit

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes: > One concern that I have is that, from personal experience, the ability > for bugpoint to reduce the set of optimization passes applied in order > to reproduce a bug is extremely helpful. I understand your desire to > decouple the logic somewhat, and maybe there's some way to generalize > that

David, Please find attached 2 diffs. Please notice that RemoteRunSafely.sh may get moved to the test suite sub-tree. We have targeted different areas fso far which is great. What's your plan? I have been thinking of using -run-custom and -safe-run-custom argumants for the cross-tools to keep bugpoint out of knowing any target details ans such. Best regards, Viktor ----- Original Message

On Tue, May 23, 2017 at 2:40 PM Reid Kleckner <rnk at google.com> wrote: > We have the LLVM_DISABLE_CRASH_REPORT environment variable, but that's > more about whether we should do crash reporting or not. > > It would be pretty reasonable to have another one to disable all this > stuff. It would also be reasonable to have a cmake option that compiles > this stuff away,

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);

Hi Viktor, I did not see your patches, can you send them again. Here are the changes that I have made that seem to get remote execution working for bugpoint. I have not yet changed the test system to provide -remote- client and -remote-port. David -------------- next part -------------- A non-text attachment was scrubbed... Name: patch2 Type: application/octet-stream Size: 1906 bytes Desc:

Hey all, I wanted to share a proposal <https://docs.google.com/document/d/171ecPTeXw68fbCghdGw_NPBouWvmvUX8vePlbhhHEdA/edit?usp=sharing> to revamp the current go-to IR debugging tool: Bugpoint. i'd love to hear any feedback or general thoughts. Here's the markdown version of the doc: --- # Bugpoint Redesign Author: Diego Treviño (diegotf at google.com) Date: 2016-06-05 Status:

On Tue, Oct 28, 2008 at 12:17 PM, Prakash Prabhu <prakash.prabhu at gmail.com> wrote: > Generating reference output from raw program: <cbe><gcc> > Error running tool: [snip] > /tmp/cc08IpX8.o: In function `SyLoadModule': > bugpoint-test-program.bc.cbe.c:(.text+0x25705): undefined reference to > `dlopen' [snip] This is saying that compilation with CBE is

I tried to reduce the test case in https://bugs.llvm.org/show_bug.cgi?id=42706. Here it is crashing opt: $ ~/llvm-debug/bin/opt -use-gpu-divergence-analysis -divergence stripped.ll WARNING: You're attempting to print out a bitcode file. This is inadvisable as it may cause display problems. If you REALLY want to taste LLVM bitcode first-hand, you can force output with the `-f' option.

test/BugPoint/metadata.ll Takes about 6 seconds to run if llvm-symbolizer isn't present 13 seconds with debug info 1m30s with split DWARF/Fission So, couple of things: 1) llvm-symbolizer is /really slow/ on split-dwarf files... 2) Why are stack traces even attempted when using bugpoint? Even if it's just the 6->13s slowdown, that's still halving the speed of bugpoint in the