search for: miscompiled

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 verified that the same passes are enabled) I cannot reproduce the bug exposing the infinite loop. My guess is that one of the target independent passes is invalidat...

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 latest from svn... but quick follow up question: If it looks like a miscompilation by my s...

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

...ults 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 5.10. Sorry for not noticing yesterday. Paolo

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

...the code necessary to reproduce the bug). This > has also proven useful in the past. Is this something you intend to > keep? Yes, this is also very useful and would fit in with whatever tool does the pass reduction mentioned above. The first step would be to find the subset of code that is miscompiled. The second would be to do pass reduction (with use of DebugCounters) over that miscompiled piece of code. Isn't this how bugpoint basically operates in miscompile mode now? > My largest set of problems with bugpoint has been that bugpoint's > logic for doing things like loop extr...

...in the foot a couple times on the GCC mailing list or bugzilla by pointing out a bug that turned out to be code with subtle undefined behavior... > Alternatively a testcase could be manually constructed for the top 10 > functions in the size comparison charts, > and see whether they are miscompiled. Repeat until top 10 has no > miscompilations. Tell you what: if I get enough test cases like this, I'll write the test harness supporting it. I don't have time to do this kind of code inspection myself. There has been talk (I don't remember where) about a Clang option for dete...

...e, testing on 1 such value (or a random) value won't prove that the result is correct, but may help finding trivial miscompilations like the neon_helper case. Alternatively a testcase could be manually constructed for the top 10 functions in the size comparison charts, and see whether they are miscompiled. Repeat until top 10 has no miscompilations. > > A potential solution is "under-constrained execution": > > http://www.stanford.edu/~engler/issta07v-engler.pdf > > I will bug Dawson and Daniel and see if I can get ahold of some code > for this. Although EXE isn...

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. I've attached it. > > I will try the latest from svn... but quick follow up question: If it > looks like...

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

...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 5.10. > Perhaps just leaving out those volatile tescases which are miscompiled on other platforms, since not every volatile testcase fails for all compilers. :-) -bw