similar to: [LLVMdev] clang testing?

On Jun 27, 2008, at 1:41 PM, John Regehr wrote: > Just for fun I added clang to the list of compilers that my random > tester beats on. It found a codegen bug in short order. Would you > folks say that clang is ready for the fairly high degree of abuse > produced by my tool or would it be better to wait until it matures? > Thanks, I say beat it up and file problem reports for

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

SVA/safecode looks interesting. Is it available to play with? I grepped for strings such as "sva" "secure" "safecode" in the LLVM source tree and didn't find anything, nor did I see obvious links to implementations from the project web pages. In the short term, questions I'd be interested in answering are: What happens when embedded codes that I care

Hi folks, Below is a short list of integer undefined behaviors executed by Clang when compiling the LLVM test suite. They seem pretty self explanatory, but let me know if not, if you cannot reproduce any of them, or if it would be better for me to file bugzillas on them. This is on x64 Linux, using r108984. Thanks, John --------------------------------- CLANG UNDEFINED at

A longstanding project on the LLVM "open projects" page is to run random C code through random LLVM passes. We have found many LLVM bugs by doing the first of these, but not the second: we test only -O[0123s]. Slowly but surely, LLVM is evolving resistance to our random tester. Of course this is good, but it means that we need to keep expanding our efforts if we want to continue

I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

See below. This is on Ubuntu Hardy on ia32. Thanks, John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.

On Wed, Apr 20, 2011 at 7:50 AM, John Regehr <regehr at cs.utah.edu> wrote: >> So... Are 40 and 41 the only legal behaviors or are there more? > > Since the program invokes undefined behavior, anything goes. > > The compiler is perfectly within its rights to send a rude email to your > department chair if you compile that code. > > John > Ummmm The problem is

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.

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:

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. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

I checked out LLVM and configured like this: ./configure --prefix=/home/regehr --enable-optimized then built and installed it. Then, checked out the frontend, configured like this: ../configure --prefix=/home/regehr --enable-languages=c,c++ \ --enable-llvm=/home/regehr/z/llvm but when I try to build I get configure: error: You must specify valid path to your LLVM tree with

On Jan 19, 2009, at 5:34 PM, John Regehr wrote: > Since yesterday I've been getting the error below when building llvm- > gcc > on Ubuntu Hardy on x86. For some reason, several instances of > autoconf > are getting confused and failing to detect a stdlib.h. > > John > > > /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc >

My InlineCost refactoring has been noticed in this aspect; that may or may notbe the culprit here. A quick thing you can do is to compile with -ftime-report and compare the top few passes between versions. Dan On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote: > As part of routine testing, I run clang and llvm-gcc a lot of times. > Something happened

Since yesterday I've been getting the error below when building llvm-gcc on Ubuntu Hardy on x86. For some reason, several instances of autoconf are getting confused and failing to detect a stdlib.h. John /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/

On Mon, Sep 26, 2016 at 11:43:42AM +0100, Alex Bligh wrote: > > > On 26 Sep 2016, at 10:21, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote: > > > > Wow, that was quick! Thank you. > > > > I stumbled upon another problem: Apparently nbd-tester-client and nbdkit > > disagree on what constitutes a valid flush request. > >

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,

hi again How can i extend 5 times for effect.pulsate beats? I need that continue beat until other event client happened about my other mail, is there other solution more elegant that this? : new Effect.Pulsate(leccion[i_leccion],{duration: 5,from: 1}); thanks again rag