search for: miscompilation

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 latest from svn... bu...

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

"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

...; 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 like the neon_helper case. Are you absolutely sure it's a miscompilation? I have already shot myself 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 man...

...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. Sure, 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": &...

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 runs with -output argument to supply the expected output, -args to give the program arguments, and -tool-args give arguments to, in this case, llc. The problem is that I can't seem to get bugpoint to run this...

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

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

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 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. -------------- next part ------...

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 speccmds.err -o speccmds.stdout -f speccmds.cmd -C 403.gcc: co...

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