search for: creduce

...se clang libraries to implement better >> versions of existing tools" are doable as it seems to me. E.g. delta >> replacement based on clang. >> > > +1 as a would-be user of a tool like that. Actually John Regehr & others have implemented something like this called CReduce ( https://github.com/csmith-project/creduce ). It's still a little limited in its C++ transformation abilities but seems to provide a fairly extensible foundation & is already proving quite useful. I'm not sure whether there's sufficient meat in there for a GSoC project to improve C...

...if you (as community/maintainer) agree if it is a bug. To make matters worse, every time a component gets upgraded (internal library, extrernal library or even the tool-chain, including clang), there is a high probability of firefighting issues. Only when that fails, I spent time logging a bug (as creduce doesn't work on my system). In the best case scenario, I get an event like this weekend that states: merged. This means: I'm certain I'll have a fix in the future. Unfortunately, it is only available in the next official release, which will happen in September. And with a bit of luck,...

...element is the > constant zero, and not an additional SUB. At the moment we don’t have > support for idempotence operations, but this is something that we should > add. > The fourth write is not necessary for GCC to vectorize it (nor was in the original code), but it was a result of CReduce's attempt to converge when running ARM's GCC and inspecting the right sequence of vector instructions. (btw, CReduce is great!). In this case, shouldn't the vector operations to just add an undef to the fourth lane? Would back-ends recognize it as a AVX/NEON/AltiVec instruction, or jus...

Awful though it may seem, we sometimes do get crashes in the compiler, usually because of some unhandled scenario we never thought of. Unfortunately this typically happens when compiling very large pieces of code, so narrowing down the context of the crash can be difficult. When CLang/LLVM crashes it very helpfully creates a temporary pre-processed file along with a shell script to run this

Hi, maybe you can have a look at the CReduce project: http://embed.cs.utah.edu/creduce/ This project implements many source-to-source transformations of C programs, e.g. removing functions, changing variable names, deleting branches in if-statements, etc. Some of these are purely based on the source code, other use the Clang frontend. Hope...

On Apr 2, 2012, at 3:07 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> Ah OK. I would have loved to have such a tool, but as a non-clang >> expert, I can obviously not judge if it is suited. Maybe you are aware >> of other projects suitable for GSoC, > But still many things in "Use clang libraries to implement better > versions of existing

Hi all, I'm doing the program slicing [1] in LLVM. Now I implemented the Weiser's algorithm [2] in a simple way by writing a plugin to analyze the IR. My final goal is to slice the source code, thus I recorded all the lines of source code to be sliced. The last step is to delete the lines which are not in the program slice. However, I met a problem when deleting the source code directly:

> Ah OK. I would have loved to have such a tool, but as a non-clang > expert, I can obviously not judge if it is suited. Maybe you are aware > of other projects suitable for GSoC, But still many things in "Use clang libraries to implement better versions of existing tools" are doable as it seems to me. E.g. delta replacement based on clang. -- With best regards, Anton

Thank You for suggestion Adrian! Generated reproducer for the crash using clang reproducer and CReduce. ::Attachment:: C file. NIT: some clean up is done on this file just to silent some compiler warnings(like implicit declaration etc.) Crash can be reproduced using above test case with following commandline: $clang -g -O3 -mllvm –enable-partial-inlining creducegenerated-cleaned.c -c ---CRASH--- $c...

Hi folks, While building openmpi.4.0.0(Optimized debug build), using trunk clang we encountered a crash(assertion failure). Initially assertion seems trivial: [...] void llvm::DwarfExpression::addFragmentOffset(const llvm::DIExpression*): Assertion `FragmentOffset >= OffsetInBits && "overlapping or duplicate fragments"' failed. [...] But, narrowing to RC. We discovered

...he tool, but with the caveat of still being documented and designed towards delta reduction. ### Command-Line Options We are proposing to reduce the plethora of bugpoint’s options to just two: an interesting-ness test and the arguments for said test, similar to other delta reduction tools such as CReduce, Delta, and Lithium; the tool should feel less cluttered, and there should also be no uncertainty about how to operate it. The interesting-ness test that’s going to be run to reduce the code is given by name: `--test=<test_name>` If a `--test` option is not given, the program exits...

This is almost ideal for SLP vectorization, except for two problems: 1. We have 4 stores to consecutive locations, but the last element is the constant zero, and not an additional SUB. At the moment we don’t have support for idempotence operations, but this is something that we should add. 2. The values that we are subtracting come from 3 loads. We usually load 4 elements from memory, or

Interesting. If it is generating yaml files that can't be decoded, then definitely sounds like a bug. If you can provide a reduced test case we can try to fix it, but admittedly it can often take some effort to generate a reduced test case. The best way is to use creduce. Use cl or clang-cl and write the pre-processed output to a file, then run creduce on that file with a test that basically roundtrips from obj2yaml to yaml2obj and return 1 if there's an error. Then let it run for a couple of hours (or days) and you should come back to a minimal repro. Grant...

...he tool, but with the caveat of still being documented and designed towards delta reduction. ### Command-Line Options We are proposing to reduce the plethora of bugpoint’s options to just two: an interesting-ness test and the arguments for said test, similar to other delta reduction tools such as CReduce, Delta, and Lithium; the tool should feel less cluttered, and there should also be no uncertainty about how to operate it. The interesting-ness test that’s going to be run to reduce the code is given by name: `--test=<test_name>` If a `--test` option is not given, the program exits...

I'm now thinking that there's a bug in either obj2yaml or yaml2obj, because if I run just those two tools on my codebase it generates yaml files that can't be decoded, will try now to not add any section to the obj file in llvm-objcopy to see if I can link with obj files that I rewrite (but without adding symbols or sections). One of the bugs that do annoy me is that the timedatestamp

...the patch author > reproduce the problem or at least understand the bug. > > This can take many forms. They can link directly to an LLVM buildbot, > which should be self-explanatory as far as reproduction goes. It can be > an unreduced crash report. If they're nice, they can use CReduce to make > it smaller. But, a reverter can't just say "Revert rNNN, breaks > $RANDOM_PROJECT on x86_64-linux-gu". If they add, "reduction forthcoming" > and they deliver on that promise, I think we should support that. > > In other words, the bar to revert shou...

.../bugs.llvm.org/show_bug.cgi?id=37728 ) which might be a nice place to start so that you can try replicating the results. In particular https://bugs.llvm.org/show_bug.cgi?id=42138 is a bug that one of our interns found recently using the check_cfc script with llvm test-suite (and then reducing with creduce). Unfortunately it was right at the end of his internship so he didn't get a chance to try and fix it. It might be a good starting point to have a go at replicating the failure and then trying to figure out what's happening and fixing it (assuming that it's still present). I'm sur...

...wrote: > Interesting. If it is generating yaml files that can't be decoded, then > definitely sounds like a bug. If you can provide a reduced test case we > can try to fix it, but admittedly it can often take some effort to generate > a reduced test case. The best way is to use creduce. Use cl or clang-cl > and write the pre-processed output to a file, then run creduce on that file > with a test that basically roundtrips from obj2yaml to yaml2obj and return > 1 if there's an error. Then let it run for a couple of hours (or days) and > you should come back to a m...

...if you (as community/maintainer) agree if it is a bug. To make matters worse, every time a component gets upgraded (internal library, extrernal library or even the tool-chain, including clang), there is a high probability of firefighting issues. Only when that fails, I spent time logging a bug (as creduce doesn't work on my system). In the best case scenario, I get an event like this weekend that states: merged. This means: I'm certain I'll have a fix in the future. Unfortunately, it is only available in the next official release, which will happen in September. And with a bit of luck,...

Hi Paul, Thanks for your useful guidelines, may I confirm with you the steps list below is correct or not? 1. find sample code (.c) 2. using different options(pass) to compile sample code by clang with/without "-g" 3. objdump the output.o and outout-g.o 4. compare two file of text section check if there has any difference. 5. if find difference, great, file bug and fix it. Please