[creduce-dev] branch for upcoming release

The other day Yang merged the PR from berolinux for LLVM 16 and also fixed a few problems (thanks to both!). Since then I've been working towards a version that we can release, it is here: https://github.com/csmith-project/creduce/tree/creduce-2.11 Building using cmake, things look good on

Re: [creduce-dev] creduce with yarpgen

The key here, I think, is to ensure that your files both #include a header that has a prototype for the test function, and then to reject any variant that triggers the compiler warning where the prototype and the definition have a different number of arguments. Another solution would be to

Re: [creduce-dev] How does C-reduce work for other other languages?

An example of a pass that works broadly across languages is the one that removes entire lines from a file. Something you might do is reduce a large fortran program (or whatever) and then when C-Reduce finishes, it tells you which passes actually worked. So then those are the ones you might

Re: [creduce-dev] Delta source code

Hi, this appears to be a mirror of it: https://github.com/mpflanzer/delta John On 12/28/20 4:18 PM, Volker Weißmann wrote: Hello, on your website (https://embed.cs.utah.edu/creduce/) you compare creduce to a tool called "Delta". Unfortunatly, the link http://delta.tigris.org/ is dead.

Re: [creduce-dev] question on creduce usage

Hi Jack, I believe the --save-temps command line option will give your the paper trail that you want here, could you give that a try? Do this on a machine with plenty of free disk space. The version of the file being reduced that is in the original location where you invoked C-Reduce is

Re: [creduce-dev] C-Vise project introduction

Hi Martin, this looks great. and when he announced a final comparable port (2 years ago) there was still no feedback. This isn't quite right, we did discuss this with Moritz. Our reservations about adopting the big patch centered around a few missing features in it, a question about who

Re: [creduce-dev] halfempty algorithm for creduce?

Thanks Vegard! This is very useful to know. I'll just add that the top-level result here, where C-Reduce produces a smaller final output, but takes longer to do it, is basically the entire point of C-Reduce. We spent a lot of effort making it aggressive, and quite a lot less effort making it

Re: [creduce-dev] halfempty algorithm for creduce?

Hi Nico, it would be great if you could give us any speedup numbers your big machine. It could easily be time to increase the default number of cores that we use. Limiting C-Reduce to 4 cores by default was based on a few observations we made on some quite old hardware. Also, the actual

Re: [creduce-dev] halfempty algorithm for creduce?

Thanks again, this was all stuff that needed fixing for sure!! Ugh, sorry, replied to wrong mail here, plz ignore. John

Re: [creduce-dev] halfempty algorithm for creduce?

Thanks again, this was all stuff that needed fixing for sure!! John On 6/13/19 3:00 PM, John Regehr wrote: https://blog.regehr.org/archives/749 Note that the performance numbers are way old. If you have a few slow reductions how about post them here and maybe I can find time to play around

Re: [creduce-dev] halfempty algorithm for creduce?

https://blog.regehr.org/archives/749 Note that the performance numbers are way old. If you have a few slow reductions how about post them here and maybe I can find time to play around with increasing the speedup. John On 6/13/19 2:56 PM, John Regehr wrote: Hi Nico, C-Reduce invented

Re: [creduce-dev] halfempty algorithm for creduce?

Hi Nico, C-Reduce invented that approach years before halfempty existed :). You can increase how many cores it's willing to use with a command line option, please give this a try and let us know if this gives any more speedup. John On 6/13/19 2:54 PM, Nico Weber wrote: Hi, creduce often

[creduce-dev] visualization of c-reduce's development history

https://www.youtube.com/watch?v=2NSX5Gr_bYo :)

Re: [creduce-dev] creduce - ignore a pass

Great, yes, that's definitely the quick way to make this happen. I can add a command-line option for skipping passes but I won't be able to do that this week. John On 5/7/19 6:48 AM, Martin Liška wrote: On 5/7/19 2:31 PM, Konstantin Tokarev wrote: 07.05.2019, 15:27, "Martin Liška" :

Re: [creduce-dev] C-Reduce 2.9.0 Released

Yay!!! Thanks for pushing this out, Eric. John On 5/5/19 8:08 PM, Eric Eide wrote: C-Reduce 2.9.0 is released! Get it from GitHub: https://github.com/csmith-project/creduce/releases/tag/creduce-2.9.0 Or if you want the official tarball:

Re: [creduce-dev] development stuff

I guess it depends on what people want. Can we talk about this next week? Sure, but I'll tell you what I want, which is that if you can make time for this we do a C-Reduce for LLVM 7 since this will benefit distros that are stuck on that version for a while, which is pretty common. Then we

Re: [creduce-dev] development stuff

I meant to add that I think it's time to nuke the autoconf stuff, unless there's some compelling reason to keep it. John On 2/22/19 10:29 PM, John Regehr wrote: Eric, do you envision an LLVM 7 based C-Reduce release or should I start pushing changes for LLVM 8? I'm moving our README

[creduce-dev] development stuff

Eric, do you envision an LLVM 7 based C-Reduce release or should I start pushing changes for LLVM 8? I'm moving our README and INSTALL files to markdown, had wanted to do that for a long time. John

Re: [creduce-dev] LLVM 7 and 8

The LLVM 8 release is imminent, so we sort of missed the boat on LLVM 7. John On 2/22/19 8:16 AM, Eric Eide wrote: Martin Liška writes: Any expectation when a new release will happen? No, I can't give you a specific date. I'm sorry. This is on my to-do list, and I want to get to it as

Re: [creduce-dev] [RFC] Adding passes for reducing clang crash reports

Hi Reid, that's odd, I got Amy's mail from the list as usual. I reproduce it below. John --- Hi all, Reducing crashes in clang is a common task for compiler developers, so we would like to make it faster. Clang produces

Re: [creduce-dev] [RFC] Adding passes for reducing clang crash reports

Hi Amy, I agree that reducing include-heavy C++ is clunky. Before running C-Reduce, I usually preprocess using "-P" which leaves out the line markers. I guess that doesn't help you if you are using a file produced by an automated crash reporter. As Eric says, unifdef may help, it is

Re: [creduce-dev] Thanks letter

Hi Tony! (1) We could add a option to let the user set how long the program is expected to run at most, once that time passed, creduce can kill the process and treat it as one failed reduce and just continue try something else. The reason we need this is that sometimes after reducing the

[creduce-dev] LLVM 7 and 8

Does anyone have time to update C-Reduce to LLVM 7? I think we should do an LLVM-7-based release even if LLVM 8 is coming out fairly soon (I imagine it is) since OS distributions may be stuck on LLVM 7 for a while. John

Re: [creduce-dev] C-Reduce Script for an OpenGL program

Thanks Vegard. Adding a timeout of 3s to ./a.out did seem to go well. I gave it about 4 or 5 days, but eventually lost patience after a day or so of "pass_lines". (The preprocessed cpp file was 302211 lines btw.) Well, ugh. I don't know of a faster way to do this: pass_lines is hierarchical

Re: [creduce-dev] Creduce example with potential improvements

I was sure we had a class -> struct transformer but it looks like not, will see if we can do that one. We do a lot of similar stuff. Russell, your list is great, the problem is we've all moved onto other jobs or projects and it's hard to find time for active C-Reduce development. John On

Re: [creduce-dev] LLVM 6

Eric, also, if you have time to make some sort of rudimentary release checklist for C-Reduce, I can take care of subsequent releases more effectively. John On 3/9/18 11:39 AM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: Eric, if you don't have time for a release I

Re: [creduce-dev] LLVM 6

OK travis is happy again. Push the button anytime, Eric. John On 3/9/18 11:39 AM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: Eric, if you don't have time for a release I'll do it. I still want to do this. Obviously I wasn't very successful recently, but I think t

Re: [creduce-dev] LLVM 6

I want you to do it too! But I want a release more than I want you to do the release. John On 3/9/18 11:39 AM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: Eric, if you don't have time for a release I'll do it. I still want to do this. Obviously I wasn't very succ

[creduce-dev] LLVM 6

OK, we managed to sit out LLVM 5 without a C-Reduce release, but LLVM 6 just came out so now would be a good time. I just pushed changes updating to LLVM 6 (nothing broke, it looks like). Later today when I'm on a Linux machine I'll update our docker stuff. Eric, if you don't have time for a

Re: [creduce-dev] cmake bug?

hanism we use there: https://cmake.org/cmake/help/v3.0/command/configure_file.html John On 01/30/2018 07:32 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: There's something weird going on where the "creduce" file isn't getting generated from "creduce.in"

[creduce-dev] cmake bug?

There's something weird going on where the "creduce" file isn't getting generated from "creduce.in" after I modify the latter. So I change creduce.in, run "make install", and then I just get the old version of the file. I can get the newer version if I remove my build directory and run cmake

Re: [creduce-dev] Making creduce more parallel

I would suggest that you start out dealing only with one or two passes, perhaps the line remover and the token remover. These do some heavy lifting, hopefully never crash, and are always easy to understand. I think if you do this and don't worry about things like command-line arguments (or

Re: [creduce-dev] Making creduce more parallel

How are the passes / reducers structured right now? If we can generate all of a pass's potential reductions up front, then they can be inserted into the queue in a random order to reduce the likelihood of conflicts. If the passes don't separate generating a potential reduction from testing it,

Re: [creduce-dev] A reduction attempt that creduce handled poorly, where delta was able to make progress

Ah. I should have mentioned that I needed to use delta's -in_place option to get delta to work. Does creduce have an equivalent or do I have to manually do the backups and restoration on any build or test failure? To support parallelism I removed C-Reduce's ability to reduce in place, you'll

Re: [creduce-dev] A reduction attempt that creduce handled poorly, where delta was able to make progress

Hi Tony, thanks for the note and the examples. That's a pretty serious interestingness test you have there! One thing that might be going wrong is that C-Reduce is running multiple processes in parallel and they are cd-ing to /opt/llvm/whatever and stomping each other. Can I ask you to

Re: [creduce-dev] Making creduce more parallel

Hi Nick! This sounds like cool work. It sounds like you're using C-Reduce as a fuzzer, basically? I'm afraid to say that 6 hours is not really that bad when dealing with C++, I think a number of us here have seen reductions take quite a bit longer than that. I'm not sure why C-Reduce

Re: [creduce-dev] Cherry-Picking Commits?

It would be simpler, I imagine, to simply merge master into llvm-svn-compatible as desired. As you've probably noticed I do this periodically to keep the skew minimized. John

Re: [creduce-dev] Error building creduce

Faraz, you will need to tell us what version of C-Reduce you are using, what version of LLVM/Clang you are using (specifically), and what options you passed to the configure script. John On 9/13/16 11:08 AM, Faraz Hussain wrote: Hi, I get this error when executing creduce's make: In file

Re: [creduce-dev] release time

Can I get someone to add the nonsense to the INSTALL file about under which circumstances Clang must be used to build C-Reduce instead of GCC, and how to do that for autoconf and cmake? Thanks! John On 09/07/2016 01:36 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes:

Re: [creduce-dev] release time

Ok, I'll merge the llvm-svn-compatible branch into the trunk and then you can do your stuff, Eric. John On 9/7/16 1:36 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: Since LLVM 3.9 is out and C-Reduce development seems quiet at the moment, we should do a new r

Re: [creduce-dev] reduction using dynamic information

Yang, excellent, thanks! extra work is actually quite important. Without it, it's almost certain that we would end up repeatedly rewriting the first occurrence of "!__creudce_printed_1", because "--counter=1" would always result in valid transformation. Nice, I didn't think of that. I'm

Re: [creduce-dev] reduction using dynamic information

Yes, I think we can implement this. My concern is that searching only the first program point where a wrong value is taken might not always lead to optimal output. For example, we may get a smaller reduced program by keeping the second failing point. In other words, we could lose other search

Re: [creduce-dev] reduction using dynamic information

/12/16 1:00 PM, Yang Chen wrote: On 2016-07-12 08:36, John Regehr wrote: I have two small tweaks to suggest. We should print the value only once (or else we might get a lot of output for an expression that lives in a loop) and we should make the value easy to recognize in case the program prints

Re: [creduce-dev] reduction using dynamic information

t's better to simply include stdio.h. I think this'll be helpful in working around C-Reduce's lack of constant folding and will help eliminate the setup code needed to observe miscompilations in the wild. John On 7/12/16 12:50 AM, Yang Chen wrote: Hi John, On 2016-07-11 15:21, John Regehr wrote:

[creduce-dev] reduction using dynamic information

I've been reducing some difficult wrong code bugs lately and C-Reduce tends to get stuck sometimes, it just can't see the transformations that need to be done. One idea I've had, than I think will help out, is to convince C-Reduce to replace a variable (or other expression) with a value that

Re: [creduce-dev] Nits in Test Reduction @ 9b0d493

void fn1() { a << 0; } I hear you but these days clang-format puts that kind of function on a single line. We can provide it with a different style preference if we want, of course. John

Re: [creduce-dev] Nits in Test Reduction @ 9b0d493

The parens are weird, I'll look into it. This example looks pretty-printed to me, is there something unpretty about it? John On 6/25/16 10:41 PM, Eric Eide wrote: At commit 9b0d493 (current master), reducing test #1 gives me this result: - long a; void(fn1)() { a << 0; } int main() {

Re: [creduce-dev] Nits in Test Reduction @ 9b0d493

(I didn't run tests #4 and #5, because they require Frama-C and KCC, respectively.) Note that instead of Frama-C and lots of weird command-line options you can now just use tis-interpreter and zero command line options, and you do not even need to build lots of weird OCaml crap, just download

[creduce-dev] cache

Just thinking aloud a bit here... C-Reduce used to have a cache for delta tests. Since the test case usually gets smaller, the cache only hits when C-Reduce's execution becomes repetitive near the final fixpoint. The cache sometimes used a lot of memory. I ended up taking it out when it

Re: [creduce-dev] [RFC] Switching from Perl to Python

Hi Moritz, this is cool. I've thought about the Perl vs Python issue a number of times and basically I just do not love Python no matter how many times I start writing it. On the other hand I can probably get over this. My guess is that the speedup you're seeing is mostly due to running

Re: [creduce-dev] OS X Configure-time Error (was Re: Run-time Perl Warnings from C-Reduce bc92ff4)

I have latest of everything incl xcode 7.3. John On 4/18/16 5:15 PM, Eric Eide wrote: Eric Eide writes: clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk' Indeed, there seems

Re: [creduce-dev] OS X Configure-time Error (was Re: Run-time Perl Warnings from C-Reduce bc92ff4)

/c++/v1/cassert\ :21:10: fatal error: 'assert.h' file not found #include ^ 1 error generated. On 4/18/16 5:10 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: Also I still can't successfully configure C-Reduce against the LLVM 3.8 binaries distributed from the LLVM web

[creduce-dev] paper of interest to C-Reduce users

http://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2016/IWOCL_CL-Reduce.pdf John

Re: [creduce-dev] towards a release

fun-- one thing works on OS X and the other works on Linux. Yay autotools! John On 3/10/16 10:21 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: Let's work towards a release sometime in the next few weeks. It's on my list. Note that I will be in Germany next week, so I

Re: [creduce-dev] Nit

In general I agree but sometimes people move to the branch when close to a release since the new version becomes more important than the old one. Sorry, I find it hard to get worked up about this sort of hygiene. I'll be more professional once I'm being paid to write C-Reduce. John On

[creduce-dev] towards a release

Now that LLVM 3.8 is out I've merged the llvm-svn-compatible into master, and deleted llvm-svn-compatible to help people remember not to use it for now. Let's work towards a release sometime in the next few weeks. Eric, I noticed that while I can build C-Reduce against an LLVM 3.8 that I

[creduce-dev] templates

It's great that people have been submitting pull requests lately (and that Yang has been accepting them)! I was thinking about sitting down and writing a clang_delta pass that would take the example below (from C-Reduce issue #66) and push first the char * template parameter and second the

Re: [creduce-dev] a few crashes in llvm-svn-compatible

Awesome, thanks Yang! I wonder what's going on on your magical Mac? John On 1/24/16 10:11 AM, Yang Chen wrote: OK. Fixed in master and llvm-svn-compatible. - Yang On 2016-01-19 02:22, John Regehr wrote: I've updated the llvm-svn-compatible branch and am doing some testing against

Re: [creduce-dev] a few crashes in llvm-svn-compatible

Ok let's just make sure of a couple more things. Can you make sure you are also building C-Reduce using Clang? I do this via autoconf: ./configure CC=clang CXX=clang++ --prefix=$HOME/creduce-install I doubt this matters but we might as well make sure. Then run this on the attached file:

Re: [creduce-dev] a few crashes in llvm-svn-compatible

that it's the third time at which I couldn't reproduce the crashes for Mac... - Yang On 2016-01-19 02:22, John Regehr wrote: I've updated the llvm-svn-compatible branch and am doing some testing against the LLVM-3.8 release branch. Attached are a few clang_delta crashes, if someone has time to fix

[creduce-dev] a few crashes in llvm-svn-compatible

I've updated the llvm-svn-compatible branch and am doing some testing against the LLVM-3.8 release branch. Attached are a few clang_delta crashes, if someone has time to fix. Thanks, John reduce.tar.gz Description: GNU Zip compressed data

Re: [creduce-dev] parallel tuning

Thanks! John On 11/17/15 4:38 PM, Markus Trippelsdorf wrote: On 2015.11.17 at 15:08 +0100, John Regehr wrote: Thanks Markus! If you have time to run 2,3,5 I'd be curious to see those too. creduce -n 1 --backup ./check.sh bug244.cc 2576.49s user 300.02s system 100% cpu 47:47.16 total

[creduce-dev] work to do

I wrote a quick blog post about reducing non-preprocessed code, the example at the bottom shows that we still have plenty of low-hanging fruit for clang_delta to clean up. Yang has long been heroically attacking these problems, does anyone else have time to take a stab? John

Re: [creduce-dev] parallel tuning

Yes. I run creduce on a 2x10x8 ppc64le machine often and I definitely don't want to use 160 tests in parallel... Aw come on, that would be awesome. You should try it once just to see what happens. But anyway I just pushed some code implementing the change I mentioned earlier today that (1)

[creduce-dev] puzzling clang_delta crash

See below an interaction I just had with clang_delta. It crashes when run on a variant but then fails to crash when that file is renamed. Perhaps clang is behaving differently on a .cpp file vs. a file with no extension? In any case, C-Reduce's current strategy of copying a crash-inducing

Re: [creduce-dev] puzzling clang_delta crash

Sorry wrong paste http://www.cs.utah.edu/~regehr/bug.tar.bz2 On 11/12/15 2:21 PM, John Regehr wrote: Yep. Yang-- tarball including the offending command as cmd.sh can be found here, if you have time to take a look: http://www.cs.utah.edu/~regehr/hot.html John On 11/12/15 1:43 PM, Yaron

Re: [creduce-dev] finishing up current c-reduce work

LLVM will sooner or later (maybe even for 3.8) move to CMake-only so at that point we might want to do that same. Otherwise I don't care. John On 11/9/15 4:11 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: I feel sure that I've broken Windows since I don't have a W

Re: [creduce-dev] unifdef

so ideally this behaviour should be kept in the reduced example. It may make reducing much harder, though, so we could probably start with -w and see how it goes. Yaron 2015-11-01 1:19 GMT+02:00 John Regehr <reg...@cs.utah.edu <mailto:reg...@cs.utah.edu>>: Well, I probab

Re: [creduce-dev] unifdef

for the includes as first pass, usually most of them are not required, typically repeats for five-ten levels of nested includes. Maybe this should be merged into unidef or added as its own pass. Yaron 2015-10-31 11:05 GMT+02:00 John Regehr <reg...@cs.utah.edu <mailto:reg...@cs.utah.edu>>:

[creduce-dev] unifdef

I just merged the new pass that does partial resolution of ifdefs. For the 196 transitive include files that come from a C++ hello world on OS X (not making this up) the unifdef pass by itself gives a 57% reduction (in 352 seconds) if we choose -D first and -U second for each CPP symbol.

Re: [creduce-dev] unifdef

Yaron, thanks for sharing! I think you are describing a more difficult reduction than any I have attempted. First, every interestingness test was slow to compile, about 10s. Ouch. Second, Boost-using code and Boost-headers usually include many more includes than actually required for a

Re: [creduce-dev] unifdef

. OTOH, g++ 4.9.3 accepts this code with the include in *either* location. If creduce can handle such code automatically it would be really great as manually+creducing such examples is no fun. I'd like to see the final result... 2015-10-31 22:17 GMT+02:00 John Regehr <reg...@cs.utah.edu &l

Re: [creduce-dev] unifdef

Well, I probably did something wrong but using this interestingness test: g++ -c -std=c++11 -fsyntax-only incremental_components.cpp -w && ! clang++ -c -std=c++11 -fsyntax-only incremental_components.cpp -w C-Reduce rather quickly came up with this: constexpr int x0() { return

Re: [creduce-dev] multifile creduce

One more thing to add - Johan sent us two patches. One is similar to what Moritz's patch does. I am going to combine these two. Perfect! Johan's other patch is for including search files. I want to think about that one more. I'll take care of integrating it if that's the right thing to

Re: [creduce-dev] Finding `clang' at Run Time (Re: multifile creduce)

I would probably lean towards feeding this kind of information to clang_delta using an environment variable rather than pushing it through C-Reduce. How does that strike people? John On 10/20/15 11:48 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: We can definitel

Re: [creduce-dev] multifile creduce

It seems like that patch is doing the same thing I do in mine but that it is much more complete than mine. OK-- we'll work to get it merged and then I hope you'll test it out and let us know how things are doing so we can improve it further. Thanks, John

Re: [creduce-dev] multifile creduce

Since there's a bit of interest in multifile reduction, I thought I'd share my remaining plans: - add a pass for removing comments en masse (they currently get removed slowly and badly by lexical-minded passes); probably this wants to be done after the line-based passes first run? - attempt

Re: [creduce-dev] multifile creduce

Thanks Markus, I hadn't seen that! I probably would have added multi-file support earlier if I'd known that people wanted it. John On 10/19/15 7:34 PM, Markus Trippelsdorf wrote: On 2015.10.19 at 18:17 +0200, John Regehr wrote: I've pushed changes to C-Reduce that support reducing more

[creduce-dev] multifile creduce

I've pushed changes to C-Reduce that support reducing more than one file at a time. Use cases include: - reductions for LTO bugs - reducing a file + its transitive includes when, for whatever reason, reducing the preprocessed file does not work (As always, if you can reduce a preprocessed

Re: [creduce-dev] Close to New C-Reduce Release

Eric, I was trying to build C-Reduce using g++ and it failed. This can't be correct behavior. This has always worked in the past. John On 9/22/15 8:55 PM, Eric Eide wrote: John Regehr <reg...@cs.utah.edu> writes: Current C-Reduce works just fine on OS X but I have three things t

Re: [creduce-dev] Close to New C-Reduce Release

Current C-Reduce works just fine on OS X but I have three things that we should fix: "configure" fails for me on Ubuntu 14.04, see the relevant part of config.log below. I don't understand why autoconf is invoking g++ when ostensibly attempting to check if it can compile/link with LLVM. We

Re: [creduce-dev] Close to New C-Reduce Release

I haven't done OS X. I'll do that. Do we have a story for testing Windows? Nope. Is there anyone on the list who could double check that our current master branch works both under cygwin and native Windows compilation? John

Re: [creduce-dev] More llvm-svn changes required?

Reid, thanks! As you observed we've been lax on starting the new branch but it sounds like it is time to do that now. John On 12/30/14, 4:26 PM, Reid Kleckner wrote: LLVM no longer installs llvm/Config/config.h, which is good, considering it used to cause macro redefinition conflicts with

[creduce-dev] C-Reduce 2.2

We've just released version 2.2 of C-Reduce, a program that takes a C or C++ file that triggers a compiler bug and turns it into a much smaller file that still triggers the bug. This release contains many minor improvements and compiles against LLVM/Clang 3.5.0. Please grab the new version

Re: [creduce-dev] llvm-svn-compatible merged

, John Regehr wrote: Only a couple of little changes were needed to make C-Reduce llvm-svn-compatible work with LLVM 3.5. I've pushed these and also merged this branch into the master and deleted it. Eric and Yang, you should look over my changes. So far the master is only lightly tested but I

Re: [creduce-dev] Creduce Macro Analysis

Hi Rand, C-Reduce works fine on code that has not been preprocessed. Whether or not it works well for your particular problem can only be discovered by experiments. Please give it a try. I recommend using the current version from Github since our latest release is pretty old. John On

Re: [creduce-dev] C-Reduce Release

Is LLVM 3.4.1 just a bugfix release? If so, we can probably support both 3.4 and 3.4.1. Yang do you have time to look into this? If you do package topformflat *please* make sure to put it in your own directory. We'll probably rename it. The motivation for including this, Eric, is that I

Re: [creduce-dev] C-Reduce Release

The worst problem with our install story is the Perl modules. Not sure what to do about that. Some platforms don't make it easy to get these and you don't want to ask random people to use CPAN. John On 5/29/14, 10:45 AM, John Regehr wrote: Is LLVM 3.4.1 just a bugfix release? If so, we

Re: [creduce-dev] C-Reduce Release

What's wrong with CPAN? cpanm is not harder to use than avereage package manager. For example in my department it's relatively easy for people who don't have root to get the admins to install packages but they aren't as happy about random Perl modules and as Eric says, CPAN as non-root isn't

[creduce-dev] llvm 3.4

It's finally out. We should collapse the llvm-svn-compatible branch sometime soon and then do a maintenance release of C-Reduce. John

Re: [creduce-dev] llvm 3.4

Hi Markus, I believe the /tmp garbage is a symptom of parallel execution where we end up killing compiler processes that correspond to dead lines of speculation. So these files aren't created directly by C-Reduce. Does the compiler you're using support an environment variable telling it

[creduce-dev] missed constant folding transformations

Below are some programs emitted by C-Reduce that trigger bugs in the llvm-gcc-4.2 that comes with the latest Xcode. There are at least a handful of missed constant-folding transformations in these tests. For example, in the third one, 108 % 5 can be replaced with 3. I'm not suggesting that

Re: [creduce-dev] missed constant folding transformations

constant-folding. It should be easy to add. I will put it to my todo. Is Clang's constant folding easy to access? If so, then I expect this is simple. John

Re: [creduce-dev] LLVM 3.4

but maybe Yang can chime in and let us know if he did anything special. John On 11/25/13, 11:21 AM, Reid Kleckner wrote: On Sun, Nov 24, 2013 at 12:17 PM, John Regehr reg...@cs.utah.edu mailto:reg...@cs.utah.edu wrote: Is C-Reduce working pretty well for people? I use it daily and have

Re: [creduce-dev] Increase of size during reduction process

=== (-8.8 %, 817437 bytes) === pass_lines :: 2 === (-10.6 %, 830801 bytes) Will try to remove all pass lines and see what happens. Paulo Matos -Original Message- From: creduce-dev-boun...@flux.utah.edu [mailto:creduce-dev- boun...@flux.utah.edu] On Behalf Of John Regehr Sent: 02 October

[creduce-dev] line-based reduction

The line-based reduction passes use two different strategies to try to get good gains early on (both stolen from Berkeley delta). First, they start out trying to remove more lines, initially half of the test case, then 1/4, then 1/8, etc. Second, the topformflat utility is used to do various

Re: [creduce-dev] new pass

Btw, I had cases where pass_lines::0 and pass_lines::1 where running for a long time with almost no progress, while pass_lines::2 removed more than 50% quickly after that. We've seen this too! There might be some clever way to figure out which line pass to run, I'm not sure... John

Re: [creduce-dev] new pass

I think great addition to it would be binary search version of remove-unused-function. Definitely. This should be easy given the new binary search + clang pass code. There probably are a few other passes that will work well in binary search mode. Regarding pass_lines::0, I think we just

[creduce-dev] new pass

Yang has added a pass that removes function bodies and C-Reduce is now up to 5x faster than 2.1.0 when reducing large C++ codes. For these experiments he compiled against LLVM 185996, which seems to be a good version to use for now. We'd be happy to hear if others' experience matches or

Re: [creduce-dev] How to avoid read/write outside array boundaries

I agree, making these transformations avoid gratuitously stupid output is a good idea, if it can be done with modest effort. You have a challenging environment! I was about to say something similar. We appreciate all of the feedback, Kees. John

  1   2   >