similar to: [LLVMdev] Help to debug the miscompilation of a loop into an infinite loop

On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1. Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp

On Tue, Apr 10, 2018 at 3:09 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: >> >> Dear llvm-dev, >> >> >> Hi! We're collecting mis-compilation

On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1.  Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp > llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp 3.7 was released over two years ago; there have been

On 06/24/11 06:53 PM, Eli Friedman wrote: > On Fri, Jun 24, 2011 at 9:12 AM, Karel Gardas<karel.gardas at centrum.cz> wrote: >> My question is if it is a known bug or unknown in which case where to >> report it and if also include compiled *.bc file or not. > > Haven't seen it before... see > http://llvm.org/docs/HowToSubmitABug.html , and please do include the

Hi Scott, > On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: > > this is indeed a miscompilation by your system compiler. However so many > > compilers miscompiled this that a workaround was committed to svn. So you > > may want to check out llvm and llvm-gcc from svn. Alternatively, maybe > > the patch applies to llvm 2.5 too.

On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: > this is indeed a miscompilation by your system compiler.  However so many > compilers miscompiled this that a workaround was committed to svn.  So you > may want to check out llvm and llvm-gcc from svn.  Alternatively, maybe > the patch applies to llvm 2.5 too.  I've attached it. I will try the

On Fri, Jun 24, 2011 at 10:06 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > On 06/24/11 06:53 PM, Eli Friedman wrote: >> >> On Fri, Jun 24, 2011 at 9:12 AM, Karel Gardas<karel.gardas at centrum.cz> >>  wrote: >>> >>> My question is if it is a known bug or unknown in which case where to >>> report it and if also include compiled

"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

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

Dear llvm-dev, Hi! We're collecting mis-compilation bugs in gvn and mem2reg since 3.7.1. Specifically, We're interested in bugs in the following files: llvm/lib/Transforms/Scalar/GVN.cpp llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp We checked all reports in the LLVM bugzilla (https://bugs.llvm.org/), so I'd like to ask if you know any such a bug that is not reported in

> Indeed, but can't an analysis find at least one value for each variable > where the behavior is not undefined? > Such a value must exist, or the entire function is useless if it always > has undefined behavior. Good point :). > Sure, testing on 1 such value (or a random) value won't prove that the > result is correct, but may help finding trivial > miscompilations

On Tue, May 5, 2009 at 11:33 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Scott, > >> On Tue, May 5, 2009 at 12:26 PM, Duncan Sands <baldrick at free.fr> wrote: >> > this is indeed a miscompilation by your system compiler.  However so many >> > compilers miscompiled this that a workaround was committed to svn.  So you >> > may want to check

I found a case where GVN seems to miscompile an OpenCL program. What I am trying to figure out is given a bitcode file, how can I reduce it to a simpler case with bugpoint when I don't have a valid reference compiler available. Thanks for any tips, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL:

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 12/16/2009 03:21 AM, John Regehr wrote: > Hopefully the results are more fair and useful now. Again, feedback is > appreciated. I would also avoid testcases using volatile. Smaller code on these testcases is often a sign of miscompilation rather than optimization. For example, http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is miscompiled on GCC 3.4 and SunCC

On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote: > On 12/16/2009 03:21 AM, John Regehr wrote: >> Hopefully the results are more fair and useful now. Again, feedback is >> appreciated. > > I would also avoid testcases using volatile. Smaller code on these > testcases is often a sign of miscompilation rather than optimization. > For example, >

On Fri, 2010-06-04 at 20:05 +0200, Jakob Stoklund Olesen wrote: > You should fix SPUTargetLowering::LowerCall to make sure there is an unbroken chain of flag ties between CopyFromReg and BRASL. At least ARM, MBlaze, and Blackfin are doing this, if you need example code. > Thanks for the tip. This got fixed in 105601. And with that, half of the problematic tests appearing with

On 2008-06-11, at 13:16, Gary Benson wrote: > Duncan Sands wrote: > >> Can you please attach IR which can be compiled to an executable >> (and shows the problem). > > I've been generating functions using a builder and then compiling > them with ExecutionEngine::getPointerToFunction(). Is there some way > I can get compilable IR from that?

Duncan Sands wrote: > Can you please attach IR which can be compiled > to an executable (and shows the problem). I've been generating functions using a builder and then compiling them with ExecutionEngine::getPointerToFunction(). Is there some way I can get compilable IR from that? Cheers, Gary -- http://gbenson.net/

Anton and John, Thank you for the valuable info. I guess the MinGW/Cygwin path is dead, at least for now. How about the problem of registering the pass multiple times under Linux (Debian4-i386)? opt -load Release/lib/Hello.so -hello < test.bc > /dev/null opt: /autofs/steffan/a/a0/czhao/ResearchTools/LLVM/2.7/llvm-2.7/lib/VMCore/Pass.cpp:234: