buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)
Alp Toker
alp at nuanti.com
Tue Jun 10 01:17:33 PDT 2014
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
More information about the cfe-commits
mailing list