search for: creduced

On Tue, Apr 3, 2012 at 11:37 AM, Jim Grosbach <grosbach at apple.com> wrote: > > 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,

Hi all, First of all, I'm sorry to create a separate thread on the mailing list, I have disabled all mails from it. I just read the thread about the bug closing protocol thanks to LLVMWeekly. (http://lists.llvm.org/pipermail/llvm-dev/2018-June/123955.html) I've noticed a lot of reactions from people involved with the solving part of the bugs. So I'm putting out the loggers point of

On 14 October 2013 18:15, Nadav Rotem <nrotem at apple.com> wrote: > 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. > The fourth write is not necessary for GCC to vectorize it (nor was in the

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 this helps, Jonas On Sun, Mar 17, 2013 at 7:25 PM,

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

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

Hey all, I wanted to share a proposal <https://docs.google.com/document/d/171ecPTeXw68fbCghdGw_NPBouWvmvUX8vePlbhhHEdA/edit?usp=sharing> to revamp the current go-to IR debugging tool: Bugpoint. i'd love to hear any feedback or general thoughts. Here's the markdown version of the doc: --- # Bugpoint Redesign Author: Diego Treviño (diegotf at google.com) Date: 2016-06-05 Status:

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

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.

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

Reid said: > I don't think whether a buildbot sends email should have anything to do > with whether we revert to green or not. Very often, developers commit > patches that cause regressions not caught by our buildbots. If the > regression is severe enough, then I think community members have the > right, and perhaps responsibility, to revert the change that caused it. > Our

On Wed, 24 Jul 2019 at 10:52, Oliver Stannard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Your script looks OK, though you won't want to use the -opt-bisect-limit= > option until you've found a case where code-generation changes. Instead, > that's a tool which you could use to narrow down the pass inside LLVM which > is causing the change. > > The

dumpbin has some clues. I ran dumpbin /all on both object files and diffed the results. In the good object file, Section #2 (.data) has File Pointer to Raw Data = 208, but in the bad file Section #2 (.data) has File Pointer to Raw Data = 0. Also, Section #3 (.bss) in the good file has Size of Raw Data = 4, but in the bad file Section #3 (.bss) has Size of Raw Data = 0. On Fri, Jan 26, 2018 at

So Reid, you'll be running a BoF on this at the October dev meeting? ☺ --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid Kleckner via llvm-dev Sent: Wednesday, June 20, 2018 6:12 PM To: JVApen at gmail.com Cc: llvm-dev Subject: Re: [llvm-dev] Bug-closing protocol Thanks for taking the time to report bugs! I think you are responsible for filing the most

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