similar to: [LLVMdev] bugpoint question

Hey that is great to hear that the volatile stuff is helping someone. Just broadly speaking do you know if the instcombine bug involves pointer code vs. scalar? I ask because intensive random testing has not found the bug that you are seeing. That says that either (1) the bug lies in a part of the program space we don't explore or (2) it does, but we haven't run the tests for long

Hello, John > Note that this option will be broadly useful for people developing cross > compilers since it permits specifying the simulator that runs the > compiled code. I think this option was added recently. You need to use '-run-custom' in conjunction with '-exec-command' option. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics,

On Mon, Nov 24, 2008 at 10:51 AM, John Regehr <regehr at cs.utah.edu> wrote: >> was wrong. At the time (~ 1 year ago) it was almost always >> instcombine and almost always volatile related. Now bugpoint has some >> ways to run the code by some external agent which I haven't >> investigated yet. > > People have fixed a ton of bugs (volatile and otherwise)

I've just commited a small patch that gives bugpoint the smarts to run the optimizations through valgrind when searching for errors. Pass "--enable-valgrind" to bugpoint and it will use Valgrind to test for memory errors when minimizing a testcase. When using this, you might also want to pass the -timeout=0 option, as Valgrind is about 25-50x slower than native. (The default timeout

> was wrong. At the time (~ 1 year ago) it was almost always > instcombine and almost always volatile related. Now bugpoint has some > ways to run the code by some external agent which I haven't > investigated yet. People have fixed a ton of bugs (volatile and otherwise) in instcombine since then. I will be very interested to hear what pass ends up being the problem here, and

>> http://www.st.cs.uni-sb.de/~lindig/src/quest/ > > I don't know about Tanu, but we can certainly use this in finding bugs > in LLVM! This has been listed as an "open project" for a long time [1], > but someone already implemented it, saving us the time and effort. > Thanks for the link! > > [1] http://llvm.cs.uiuc.edu/OpenProjects.html#misc_new > >

Hi folks, We recently generated some data that seemed interesting enough to share here. This is a comparison between compilers that ignores the performance of the generated code and focuses only on compiler correctness. volatile checksum errors errors avr-gcc-3.4 1.879% 0.378% avr-gcc-4.1 0.037% 0.256% avr-gcc-4.2

On Tue, Sep 2, 2008 at 12:08 PM, John Regehr <regehr at cs.utah.edu> wrote: > I get the error below (and have for a couple weeks now) when trying to > build llvm-gcc on Ubuntu Feisty. In the meantime, on Ubuntu Gutsy, > everything has been building fine. Both are release builds for x86. I've seen this error too with gcc version 4.1.2 20070626 (Red Hat 4.1.2-14). I do not see

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.

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

I understand. They only way you can keep the code bloat at a few percent or less is to aggressively eliminate nearly all run-time checks. We haven't measured our code size increases but if you have any codes to send us, we can try to get you some preliminary numbers. We do have a static array bounds checking algorithm based on the Omega integer programming library, but it is not

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

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

On Wed, Feb 4, 2015 at 11:24 AM, John Regehr <regehr at cs.utah.edu> wrote: > I am actively working towards removing poison altogether. I think a more >> accurate model of LLVM's wrapping >> flags is not poison but instead something akin to the fast-math flags on >> floating point instructions. >> > > Looking forward to seeing it. One of my students has

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

Just want to emphasize that on x86-64 and using Valgrind: LLVM compiled with LLVM gets 360 unexpected test fails LLVM compiled with GCC gets 22 unexpected test fails Of course I don't know how many of these are caused by this bitfield speculation issue. John On 11/21/2016 10:48 PM, regehr via llvm-dev wrote: > Alright, here's what seems to be happening... > > The testcase