search for: miscompiling

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

Hi, I found out that dumping the IR to disk and taking it back makes a miscompile disappear. I would appreciate your help on how to narrow down such a bug. Here are more details: when I compile one of the SPEC benchmarks with clang at -O3, the code is miscompiled producing an infinite loop. If I split the compilation using -emit-llvm and then finish the compilation from the .ll file with llc (I

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

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:

[cross-posting to the GCC and LLVM lists] I've updated the code size results here: http://embed.cs.utah.edu/embarrassing/dec_09/ The changes for this run were: - delete a number of testcases that contained use of uninitialized local variables - turn off frame pointer emission for all compilers - ask all compilers to target x86 + SSE3 - ask all compilers to not emit stack protector

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

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

"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

> 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 01/20/2010 10:10 PM, John Regehr wrote: > Hi Torok- > >> Could you also add a main() for each of these files, and do >> a very simple test that the optimized functions actually work? > > Unfortunately, testing isolated C functions is much harder than just > passing them random data! > > Consider this function: > > int foo (int x, int y) { return x+y; }

Sorry to ask about a documented use of bugpoint, but I am having trouble understanding what to do. I would like to be able to use bugpoint to simplify test cases, when the symptom is a run time difference in the testprogram behavior. That looks like what is described in the documentation as "miscompilation or perhaps code generation problems". There are examples in the LLVM doc showing

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

Hi Torok- > Could you also add a main() for each of these files, and do > a very simple test that the optimized functions actually work? Unfortunately, testing isolated C functions is much harder than just passing them random data! Consider this function: int foo (int x, int y) { return x+y; } The behavior of foo() is undefined when x+y overflows. If course it is trivial to come

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.

Hi David, > It then iterates until a simplified test case is created whose output is > still different from that of the native code. isn't that exactly what you want: a small test-case that shows the problem? Ciao, Duncan.

Yes, its what I want, but I can't figure out how to get bugpoint to accomplish this. -David ________________________________ From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thu 2/18/2010 6:06 AM To: David Dunkle Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] using bugpoint to find miscompilation/code generation problems? Hi David, > It then iterates until a simplified test

Using clang r107598 at -O1 to create reportable SPECINT 2006 results, I'm getting the output below, which is almost certainly due to a miscompilation. Known problem? Thanks, John Running (#3) 403.gcc ref base i386-m32-gcc42-nn default /home/regehr/z/specCPU2006/bin/specinvoke -d /home/regehr/z/specCPU2006/benchspec/CPU2006/403.gcc/run/run_base_ref_i386-m32-gcc42-nn.0000 -e

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