On 09/06/2014 22:51, Quentin Colombet wrote:
Hi,
On Jun 5, 2014, at 5:44 PM, Alp Toker <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]> <mailto:[email protected]>> 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: [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
To: Alp Toker <[email protected] <mailto:[email protected]>
<mailto:[email protected]>>, Eric
Christopher <[email protected] <mailto:[email protected]>
<mailto:[email protected]>>,
Jingyue Wu <[email protected] <mailto:[email protected]>
<mailto:[email protected]>>
CC: [email protected] <mailto:[email protected]>
<mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
<mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
Alexey Samsonov
[email protected] <mailto:[email protected]>
<mailto:[email protected]>
--
http://www.nuanti.com
the browser experts
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
