similar to: LLVM 1.3 Release!

June Status Update ------------------ Hi everyone, Since the last status update, we've had a lot of progress on various fronts. In particular, we passed the 15,000th commit to the llvm-commits list, we have some great new features and documentation, new people using LLVM, and (strangely enough) the MachineBasicBlock class seems to have received a lot of love. At this point, I'm

News flash: LLVM 1.2 is now available! -------------------------------------- LLVM 1.2 is the result of ~3 months of hard work by many people in the LLVM community. It contains a bunch of new features, produces substantially better code, and has many bug fixes over the 1.1 release. A detailed list of new and improved features are included in the 1.2 release notes:

News flash: LLVM 1.2 is now available! -------------------------------------- LLVM 1.2 is the result of ~3 months of hard work by many people in the LLVM community. It contains a bunch of new features, produces substantially better code, and has many bug fixes over the 1.1 release. A detailed list of new and improved features are included in the 1.2 release notes:

Hi LLVMers, Sorry for the delay, this status update should have been out a couple weeks ago. Things have been absolutely crazy here. :) May Status Update ----------------- Overall, since the LLVM 1.2 release, we've fixed several LLVM optimizations to produce better code (most have fallen into the "stop doing stupid things" category) and implemented some new optimizations. There

"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

Hey everyone. It sounds like 426 people are in for a fun weekend. It's possible that some of you may even have bugs in your code (I know, I know, not YOU... :) If this is you, read on... You might be interested in trying out the 'bugpoint' tool. It can help you when your pass crashes on a testcase. Merely tell it the input testcase and the name of your pass, and it will try to

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 Jul 8, 2009, at 12:42 AM, Viktor Kutuzov wrote: > Hello Evan, > > Thanks for looking at the patch. > >> This should use std::cerr and make sure it is wrapped inside the >> DEBUG >> macro. > > Will do. > >> 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

Ping? Still looking for advice in figuring out how and why my generated code is causing lli to crash... Talin wrote: > I've been using lli to do most of my unit tests for the compiler that > I'm writing. However, when I get a test that crashes, its difficult to > find which instruction it was that caused the crash. I tried running > bugpoint, but it didn't seem to work

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 been using lli to do most of my unit tests for the compiler that I'm writing. However, when I get a test that crashes, its difficult to find which instruction it was that caused the crash. I tried running bugpoint, but it didn't seem to work for me, and upon reading the documentation, it seems to be intended for a different purpose than finding bugs in my source program; It

On Mon, 26 Apr 2004, Finn S Andersen wrote: > Alkis Evlogimenos wrote: > > >Is there a chance you can try cvs? I would be interested to > >get a simplified test case where the allocator breaks. A lot of > >improvements went into the x86 backend since 1.2 and we currently have > >no test cases where the allocator breaks today. > I updated and recompiled and the

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

> 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

Alkis Evlogimenos wrote: >Is there a chance you can try cvs? I would be interested to >get a simplified test case where the allocator breaks. A lot of >improvements went into the x86 backend since 1.2 and we currently have >no test cases where the allocator breaks today. > > I updated and recompiled and the error is still there. It turns out that I cannot use the bugpoint

Hi all, After updating llvm+clang to r174701 by issuing make -j8 happiness The build fails with: ... make[2]: Entering directory `/local/csaba/LLVM/build-release/tools/llvm-diff' llvm[2]: Compiling DiffConsumer.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts executable lli (without symbols) llvm[2]: Compiling CrashDebugger.cpp for Release+Asserts build

Chris, I'm a little confused. I am experiencing a crash when compiling the llvm-gcc frontend. According to the bugpoint documentation, bugpoint is used to debug "optimizer crashes, miscompilations by optimizers, or bad native code generation," which seems like it implies that the frontend compiles. Also, the http://llvm.org/docs/HowToSubmitABug.html documentation seems to

* Looks like some sort of pass ordering issue; it will vectorize if indvars runs sometime between loop unswitch and the vectorizer. That insight is helpful. I scheduled Canonicalization of induction variable before loop vectorization and could get the loop vectorized. The indvars are heavily dependent on SCEV. If there a scalar like tmp which is of real type, we may not be able to get the

On 01/20/2010 10:10 PM, John Regehr wrote: > Hi Torok- > >> Could you also add a main() for each of these files, and do >> a very simple test that the optimized functions actually work? > > Unfortunately, testing isolated C functions is much harder than just > passing them random data! > > Consider this function: > > int foo (int x, int y) { return x+y; }