<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 19, 2016 at 1:10 PM, Joerg Sonnenberger via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Aug 19, 2016 at 01:03:51PM -0700, Richard Smith wrote:<br>
> On Fri, Aug 19, 2016 at 12:58 PM, Joerg Sonnenberger via cfe-commits <<br>
> <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
><br>
> > On Thu, Aug 18, 2016 at 11:33:49AM -0700, Richard Smith wrote:<br>
> > > On Wed, Aug 17, 2016 at 6:35 AM, Joerg Sonnenberger via cfe-commits <<br>
> > > <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
> > ><br>
> > > > On Wed, Aug 17, 2016 at 01:05:08AM -0000, Richard Smith via cfe-commits<br>
> > > > wrote:<br>
> > > > > Author: rsmith<br>
> > > > > Date: Tue Aug 16 20:05:07 2016<br>
> > > > > New Revision: 278882<br>
> > > > ><br>
> > > > > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=278882&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?rev=278882&view=rev</a><br>
> > > > > Log:<br>
> > > > > If possible, set the stack rlimit to at least 8MiB on cc1 startup,<br>
> > and<br>
> > > > work<br>
> > > > > around a Linux kernel bug where the actual amount of available stack<br>
> > may<br>
> > > > be a<br>
> > > > > *lot* lower than the rlimit.<br>
> > > ><br>
> > > > Can you please restrict this to Linux? I'm quite opposed to overriding<br>
> > > > system default limits, they exist for a reason.<br>
> > ><br>
> > ><br>
> > > No, that wouldn't make any sense. It's not up to the operating system how<br>
> > > an application decides to allocate memory (on the heap versus on the<br>
> > > stack), and Clang's stack usage isn't going to be significantly lower on<br>
> > > other kernels. If some BSD kernel's VM is unable to cope with this, we<br>
> > > could spawn a thread with a suitable amount of stack space instead.<br>
> ><br>
> > This is not about kernel bugs. It is about POLA -- programs are not<br>
> > supposed to alter process limits. If GCC does it, it is a GCC bug.<br>
> > That's no reason to introduce the same bug here. Using excessive stack<br>
> > space due to deep recursion might be a QoI issue, but it is<br>
> > fundamentally no different from any other out of memory condition. Those<br>
> > kill clang just as easily.<br>
><br>
><br>
> Hitting this limit does not imply that memory was exhausted, it instead<br>
> means the OS killed a process that was functioning just fine, for no good<br>
> reason.<br>
<br>
</div></div>You are allocating too much stack space.</blockquote><div><br></div><div>Whether we choose to put data on the heap or stack is not up to you or the operating system.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is no difference to heap<br>
allocations which are bound by different flags. It is just a different<br>
allocation mechanism. Even hitting a 4MB stack space limit on 64bit<br>
platforms takes quite a bit -- not even boost does that by default. As<br>
such, I hardly find it normal.</blockquote><div><br></div><div>It's not normal; that's why we're explicitly opting into it here, using the mechanism that POSIX provides to do so.</div></div></div></div>