Alp Toker
2014-Jun-06 00:44 UTC
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)
On 06/06/2014 02:33, Alexey Samsonov wrote:> Hi Alp, > > 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 > from its implementation of -Wframe-larger-than.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. 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. 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 :-) Quentin, thoughts? Alp.> > And thanks for implementing this flag! > > > On Thu, Jun 5, 2014 at 4:00 PM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > > Hi Kostya, > > Looks like our new clang diagnostic from r210293 has caught a > potential issue in compiler-rt which is now breaking the build due > to -Werror: > > /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:460:6: > error: stack frame size of 536 bytes in function > '__tsan::ReportDeadlock' [-Werror,-Wframe-larger-than] > void ReportDeadlock(ThreadState *thr, uptr pc, DDReport *r) { > ^ > [ 93%] [ 93%] Building C object > lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivti3.c.o > [ 93%] Building CXX object > lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_suppressions.cc.o > 1 error generated. > > Can you confirm that the stack frame report is legitimate? > > Assuming it is, you'll probably want to either fix the function or > relax the byte limit passed to clang in your build system. > > Let me know if I can help. > > Alp. > > > > -------- Original Message -------- > Subject: buildbot failure in LLVM on sanitizer-x86_64-linux > Date: Thu, 05 Jun 2014 15:53:19 -0700 > From: llvm.buildmaster at lab.llvm.org > <mailto:llvm.buildmaster at lab.llvm.org> > To: Alp Toker <alp at nuanti.com <mailto:alp at nuanti.com>>, Eric > Christopher <echristo at gmail.com <mailto:echristo at gmail.com>>, > Jingyue Wu <jingyue at google.com <mailto:jingyue at google.com>> > CC: gkistanova at gmail.com <mailto:gkistanova at gmail.com> > > > > The Buildbot has detected a new failure on builder > sanitizer-x86_64-linux while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/10266 > > Buildbot URL: http://lab.llvm.org:8011/ > > Buildslave for this Build: sanitizer-buildbot1 > > Build Reason: scheduler > Build Source Stamp: [branch trunk] 210295 > Blamelist: alp,echristo,jingyue > > BUILD FAILED: failed annotate failed bootstrap clang failed run > asan tests failed run msan unit tests failed run 64-bit tsan unit > tests failed run 64-bit lsan unit tests failed run > sanitizer_common tests > > sincerely, > -The Buildbot > > > > > > _______________________________________________ > cfe-commits mailing list > cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > > > -- > Alexey Samsonov > vonosmas at gmail.com <mailto:vonosmas at gmail.com>-- http://www.nuanti.com the browser experts
Quentin Colombet
2014-Jun-09 19:51 UTC
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)
Hi, On Jun 5, 2014, at 5:44 PM, Alp Toker <alp at nuanti.com> wrote:> > On 06/06/2014 02:33, Alexey Samsonov wrote: >> Hi Alp, >> >> 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 >> from its implementation of -Wframe-larger-than. > > 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. > > 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.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. Indeed, GCC documentation says: -Wframe-larger-than=len Warn if the size of a function frame is larger than len bytes. The computation done to determine the stack frame size is approximate and not conservative. The actual requirements may be somewhat greater than len even if you do not get a warning. In addition, any space allocated via alloca, variable-length arrays, or related constructs is not included by the compiler when determining whether or not to issue a warning. 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). 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. Thanks, -Quentin> > 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 :-) > > Quentin, thoughts? > > Alp. > >> >> And thanks for implementing this flag! >> >> >> On Thu, Jun 5, 2014 at 4:00 PM, Alp Toker <alp at nuanti.com <mailto:alp at nuanti.com>> wrote: >> >> Hi Kostya, >> >> Looks like our new clang diagnostic from r210293 has caught a >> potential issue in compiler-rt which is now breaking the build due >> to -Werror: >> >> /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:460:6: >> error: stack frame size of 536 bytes in function >> '__tsan::ReportDeadlock' [-Werror,-Wframe-larger-than] >> void ReportDeadlock(ThreadState *thr, uptr pc, DDReport *r) { >> ^ >> [ 93%] [ 93%] Building C object >> lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivti3.c.o >> [ 93%] Building CXX object >> lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_suppressions.cc.o >> 1 error generated. >> >> Can you confirm that the stack frame report is legitimate? >> >> Assuming it is, you'll probably want to either fix the function or >> relax the byte limit passed to clang in your build system. >> >> Let me know if I can help. >> >> Alp. >> >> >> >> -------- Original Message -------- >> Subject: buildbot failure in LLVM on sanitizer-x86_64-linux >> Date: Thu, 05 Jun 2014 15:53:19 -0700 >> From: llvm.buildmaster at lab.llvm.org >> <mailto:llvm.buildmaster at lab.llvm.org> >> To: Alp Toker <alp at nuanti.com <mailto:alp at nuanti.com>>, Eric >> Christopher <echristo at gmail.com <mailto:echristo at gmail.com>>, >> Jingyue Wu <jingyue at google.com <mailto:jingyue at google.com>> >> CC: gkistanova at gmail.com <mailto:gkistanova at gmail.com> >> >> >> >> The Buildbot has detected a new failure on builder >> sanitizer-x86_64-linux while building llvm. >> Full details are available at: >> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/10266 >> >> Buildbot URL: http://lab.llvm.org:8011/ >> >> Buildslave for this Build: sanitizer-buildbot1 >> >> Build Reason: scheduler >> Build Source Stamp: [branch trunk] 210295 >> Blamelist: alp,echristo,jingyue >> >> BUILD FAILED: failed annotate failed bootstrap clang failed run >> asan tests failed run msan unit tests failed run 64-bit tsan unit >> tests failed run 64-bit lsan unit tests failed run >> sanitizer_common tests >> >> sincerely, >> -The Buildbot >> >> >> >> >> >> _______________________________________________ >> cfe-commits mailing list >> cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >> >> >> -- >> Alexey Samsonov >> vonosmas at gmail.com <mailto:vonosmas at gmail.com> > > -- > http://www.nuanti.com > the browser experts >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140609/a171299a/attachment.html>
Alp Toker
2014-Jun-10 08:17 UTC
[LLVMdev] buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)
On 09/06/2014 22:51, Quentin Colombet wrote:> Hi, > > On Jun 5, 2014, at 5:44 PM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > >> >> On 06/06/2014 02:33, Alexey Samsonov wrote: >>> Hi Alp, >>> >>> 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 >>> from its implementation of -Wframe-larger-than. >> >> 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. >> >> 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. > > 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. > Indeed, GCC documentation says: > |-Wframe-larger-than=|len > Warn if the size of a function frame is larger than len bytes. The > computation done to determine the stack frame size is approximate > and not conservative. The actual requirements may be somewhat > greater than len even if you do not get a warning. In addition, > any space allocated via |alloca|, variable-length arrays, or > related constructs is not included by the compiler when > determining whether or not to issue a warning. > > 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). > > 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.That explains it, nice investigatory work Quentin :-) I guess the behaviour we have is a safe superset of GCC's warning for now though we might want to document it at some point. It actually sounds like we're well on the way to covering GCC's -Wstack-usage=len which includes "space allocated via alloca, variable-length arrays, or related constructs". But that also identifies whether there are unbounded/dynamic allocas which we don't have. Would it be possible to feed that information through to the frontend as well? Alp.> > Thanks, > -Quentin > >> >> 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 :-) >> >> Quentin, thoughts? >> >> Alp. >> >>> >>> And thanks for implementing this flag! >>> >>> >>> On Thu, Jun 5, 2014 at 4:00 PM, Alp Toker <alp at nuanti.com >>> <mailto:alp at nuanti.com> <mailto:alp at nuanti.com>> wrote: >>> >>> Hi Kostya, >>> >>> Looks like our new clang diagnostic from r210293 has caught a >>> potential issue in compiler-rt which is now breaking the build due >>> to -Werror: >>> >>> /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:460:6: >>> error: stack frame size of 536 bytes in function >>> '__tsan::ReportDeadlock' [-Werror,-Wframe-larger-than] >>> void ReportDeadlock(ThreadState *thr, uptr pc, DDReport *r) { >>> ^ >>> [ 93%] [ 93%] Building C object >>> lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivti3.c.o >>> [ 93%] Building CXX object >>> lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_suppressions.cc.o >>> 1 error generated. >>> >>> Can you confirm that the stack frame report is legitimate? >>> >>> Assuming it is, you'll probably want to either fix the function or >>> relax the byte limit passed to clang in your build system. >>> >>> Let me know if I can help. >>> >>> Alp. >>> >>> >>> >>> -------- Original Message -------- >>> Subject: buildbot failure in LLVM on sanitizer-x86_64-linux >>> Date: Thu, 05 Jun 2014 15:53:19 -0700 >>> From: llvm.buildmaster at lab.llvm.org >>> <mailto:llvm.buildmaster at lab.llvm.org> >>> <mailto:llvm.buildmaster at lab.llvm.org> >>> To: Alp Toker <alp at nuanti.com <mailto:alp at nuanti.com> >>> <mailto:alp at nuanti.com>>, Eric >>> Christopher <echristo at gmail.com <mailto:echristo at gmail.com> >>> <mailto:echristo at gmail.com>>, >>> Jingyue Wu <jingyue at google.com <mailto:jingyue at google.com> >>> <mailto:jingyue at google.com>> >>> CC: gkistanova at gmail.com <mailto:gkistanova at gmail.com> >>> <mailto:gkistanova at gmail.com> >>> >>> >>> >>> The Buildbot has detected a new failure on builder >>> sanitizer-x86_64-linux while building llvm. >>> Full details are available at: >>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/10266 >>> >>> Buildbot URL: http://lab.llvm.org:8011/ >>> >>> Buildslave for this Build: sanitizer-buildbot1 >>> >>> Build Reason: scheduler >>> Build Source Stamp: [branch trunk] 210295 >>> Blamelist: alp,echristo,jingyue >>> >>> BUILD FAILED: failed annotate failed bootstrap clang failed run >>> asan tests failed run msan unit tests failed run 64-bit tsan unit >>> tests failed run 64-bit lsan unit tests failed run >>> sanitizer_common tests >>> >>> sincerely, >>> -The Buildbot >>> >>> >>> >>> >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu> >>> <mailto:cfe-commits at cs.uiuc.edu> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>> >>> >>> >>> >>> -- >>> Alexey Samsonov >>> vonosmas at gmail.com <mailto:vonosmas at gmail.com> >>> <mailto:vonosmas at gmail.com> >> >> -- >> http://www.nuanti.com >> the browser experts >> >-- http://www.nuanti.com the browser experts