<div dir="ltr">Dears,<div><br></div><div>I am working on migrating company projects from gcc to clang. We have a team of serious C++ developers and are early adopters of new C++ features when our toolchain of choice supports them. New features are used in our production code where them make sense and bring us benefit. Our C++ projects are heavily templated and uses a number of highly templated libraries such as Boost and WebSocket++.</div>
<div><br></div><div>So far, in the migration process, I hit a few issues PR18408, PR18411 and PR18417. Thanks to Richard Smith's prompt response, the first two are resolved. Per Richard's advise, I would like to seek advice on the 3rd issue from the dev team.</div>
<div><br></div><div>One of <span style="color:rgb(0,0,0);white-space:pre-wrap">our projects, an llvm front end, needs -ftemplate-depth=1024 to compile its spirit-based parser. </span><span style="color:rgb(0,0,0);white-space:pre-wrap">I don't know the minimum value required, but 512 didn't do the trick.</span><br>
</div><div><br></div><div><div>N3690 annex B states:</div><div>- Recursively nested template instantiations, including substitution during template argument deduction (14.8.2) [1024].</div></div><div><br></div><div>And in gcc's manpage:</div>
<div><div>-ftemplate-depth=n</div><div>    Set the maximum instantiation depth for template classes to n.  A limit on the template instantiation depth</div><div>    is needed to detect endless recursions during template class instantiation.  ANSI/ISO C++ conforming</div>
<div>    programs must not rely on a maximum depth greater than 17 (changed to 1024 in C++0x).</div></div><div><br></div><div>Though this is not a compliance issue, but IMHO, it would be nice if clang could follow suit.</div>
<div><br></div><div>Along with the PR, I attached a naive patch (i.e. works on my system) to increase -ftemplate-depth's default to 1204. Richard kindly responded and elaborated some issues with the increase, and possible path to a proper solution.</div>
<div><br></div><div>> On some systems, increasing the recursion depth leads to stack overflows; the current limit was determined through experimentation, and we can't increase it without other code changes to reduce stack usage or to increase the stack rlimit.</div>
<div><br></div><div>We came to the consensus that rlimit could be a possible approach, but would like to get feedback from the team before I seriously dive into it (and hopefully come out with a solution proposal later).</div>
<div><br></div><div>Best,</div><div>- kenneth</div></div>