Re: [libvirt] [PATCH] maint: increase stack frame size limit

Roman Bogorodskiy wrote: > Eric Blake wrote: > > > On 05/08/2015 12:23 AM, Roman Bogorodskiy wrote: > > > Roman Bogorodskiy wrote: > > > > > >> Roman Bogorodskiy wrote: > > >> > > >>> Currently the stack frame size limit is set to 4096 and it started to > > >>> cause an error like this: > > >>> > > >>> virshtest.c:253:1: error: stack frame size of 5512 bytes in function > > >>> 'mymain' [-Werror,-Wframe-larger-than=] > > >>> mymain(void) > > >>> ^ > > >>> 1 error generated. > > >>> > > >>> Increase it to 6144. > > >> > > >> Worth to mention that it's started to show up after updating to clang > > >> 3.6. > > > > > > Any comments on this? > > > > Have you reported a possible clang regression bug to the clang folks? > > Or is the new clang version the first one to support what was originally > > only gcc's -Wframe-larger-than? At any rate, why does clang require a > > larger stack than gcc? It sounds like in addition to fixing the > > virshtest.c file to quit stack-allocating such a large amount of space, > > that you should also be letting the clang compiler folks know about > > their weakness. > > I wasn't absolutely sure that it is a clang problem. However, I did a > check now on the same libvirt revision and on the same system with > different clang versions and figured out that things work fine with: > > clang version 3.4.2 (tags/RELEASE_34/dot2-final) > > but start breaking on: > > clang version 3.5.2 (tags/RELEASE_352/final) > > So it indeed makes sense to ask clang developers what's going on; will > do that. > > I'll also try to figure out how to rewrite virshtest.c to quite > stack-allocation. > > Thanks for the feedback! I've been playing with virshtest and then figured out that there are other tests using the similar scheme (sockettest for example, and many others). I came to a conclusion that rewriting tests doesn't worth an effort, at least at this point. In the meantime, I've posted a question on the clang mailing list: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/042890.html Hopefully it'll help to understand why clang behaves this way.