<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br><div><div>On Jun 5, 2014, at 5:44 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>On 06/06/2014 02:33, Alexey Samsonov wrote:<br><blockquote type="cite">Hi Alp,<br><br>This warning should be fixed by r210301. However, consider investigating why the frame size appears to be that large. I believe we build this code with GCC as well and have seen no complaints<br>from its implementation of -Wframe-larger-than.<br></blockquote><br>CC'ing in llvmdev. Like Chandler said it could just be due to lack of stack sharing compared to GCC. There's a lot going on between the time when we generate IR from AST to the time this final machine pass is run. GCC might just be optimizing differently.<br><br>On the other hand it could indeed be that LLVM's DiagnosticInfoStackSize is giving us a different value or computation than GCC's -Wframe-larger-than. It's worth double checking that we're using a similar function frame size computation here.<br></blockquote><div><br></div><div>I do not know what exactly GCC is giving for -Wframe-larger-than, but based on the description in the documentation I would say it is likely we are not returning the same thing in LLVM.</div><div>Indeed, GCC documentation says:</div><div><dt style="font-family: Times; font-size: medium;"><code>-Wframe-larger-than=</code><var>len</var></dt><dd style="font-family: Times; font-size: medium;"><a name="index-Wframe-larger-than-437"></a>Warn if the size of a function frame is larger than <var>len</var> bytes. The computation done to determine the stack frame size is approximate and not conservative. The actual requirements may be somewhat greater than <var>len</var> even if you do not get a warning. In addition, any space allocated via <code>alloca</code>, variable-length arrays, or related constructs is not included by the compiler when determining whether or not to issue a warning. </dd><div><br></div><div>Whereas in our case, we give the actual size in bytes we reserve on the stack to store the statically known object (locals and/or spills).</div><div><br></div><div>In that case, if the reported size is completely off the actual generated code, it is worth filing a PR. Otherwise, we may need to refine the documentation the semantic of the warning for LLVM.</div><div><br></div><div>Thanks,</div><div>-Quentin </div></div><br><blockquote type="cite"><br>Let's not write off either possibility given that the LLVM value wasn't originally intended for GCC compatibility -- we just spun it that way in the frontend :-)<br><br>Quentin, thoughts?<br><br>Alp.<br><br><blockquote type="cite"><br>And thanks for implementing this flag!<br><br><br>On Thu, Jun 5, 2014 at 4:00 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a> <<a href="mailto:alp@nuanti.com">mailto:alp@nuanti.com</a>>> wrote:<br><br> Hi Kostya,<br><br> Looks like our new clang diagnostic from r210293 has caught a<br> potential issue in compiler-rt which is now breaking the build due<br> to -Werror:<br><br> /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:460:6:<br> error: stack frame size of 536 bytes in function<br> '__tsan::ReportDeadlock' [-Werror,-Wframe-larger-than]<br> void ReportDeadlock(ThreadState *thr, uptr pc, DDReport *r) {<br> ^<br> [ 93%] [ 93%] Building C object<br> lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivti3.c.o<br> [ 93%] Building CXX object<br> lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_suppressions.cc.o<br> 1 error generated.<br><br> Can you confirm that the stack frame report is legitimate?<br><br> Assuming it is, you'll probably want to either fix the function or<br> relax the byte limit passed to clang in your build system.<br><br> Let me know if I can help.<br><br> Alp.<br><br><br><br> -------- Original Message --------<br> Subject: buildbot failure in LLVM on sanitizer-x86_64-linux<br> Date: Thu, 05 Jun 2014 15:53:19 -0700<br> From: <a href="mailto:llvm.buildmaster@lab.llvm.org">llvm.buildmaster@lab.llvm.org</a><br> <<a href="mailto:llvm.buildmaster@lab.llvm.org">mailto:llvm.buildmaster@lab.llvm.org</a>><br> To: Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a> <<a href="mailto:alp@nuanti.com">mailto:alp@nuanti.com</a>>>, Eric<br> Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a> <<a href="mailto:echristo@gmail.com">mailto:echristo@gmail.com</a>>>,<br> Jingyue Wu <<a href="mailto:jingyue@google.com">jingyue@google.com</a> <<a href="mailto:jingyue@google.com">mailto:jingyue@google.com</a>>><br> CC: <a href="mailto:gkistanova@gmail.com">gkistanova@gmail.com</a> <<a href="mailto:gkistanova@gmail.com">mailto:gkistanova@gmail.com</a>><br><br><br><br> The Buildbot has detected a new failure on builder<br> sanitizer-x86_64-linux while building llvm.<br> Full details are available at:<br> <a href="http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/10266">http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/10266</a><br><br> Buildbot URL: <a href="http://lab.llvm.org:8011/">http://lab.llvm.org:8011/</a><br><br> Buildslave for this Build: sanitizer-buildbot1<br><br> Build Reason: scheduler<br> Build Source Stamp: [branch trunk] 210295<br> Blamelist: alp,echristo,jingyue<br><br> BUILD FAILED: failed annotate failed bootstrap clang failed run<br> asan tests failed run msan unit tests failed run 64-bit tsan unit<br> tests failed run 64-bit lsan unit tests failed run<br> sanitizer_common tests<br><br> sincerely,<br> -The Buildbot<br><br><br><br><br><br> _______________________________________________<br> cfe-commits mailing list<br> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a> <<a href="mailto:cfe-commits@cs.uiuc.edu">mailto:cfe-commits@cs.uiuc.edu</a>><br> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br><br><br><br><br>-- <br>Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a> <<a href="mailto:vonosmas@gmail.com">mailto:vonosmas@gmail.com</a>><br></blockquote><br>-- <br><a href="http://www.nuanti.com">http://www.nuanti.com</a><br>the browser experts<br><br></blockquote></div><br></div></body></html>