[cfe-dev] -ftemplate-depth default value in clang

[Kenneth Ho]

Dears,

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++.

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.

One of our projects, an llvm front end, needs -ftemplate-depth=1024 to
compile its spirit-based parser. I don't know the minimum value required,
but 512 didn't do the trick.

N3690 annex B states:
- Recursively nested template instantiations, including substitution during
template argument deduction (14.8.2) [1024].

And in gcc's manpage:
-ftemplate-depth=n
    Set the maximum instantiation depth for template classes to n.  A limit
on the template instantiation depth
    is needed to detect endless recursions during template class
instantiation.  ANSI/ISO C++ conforming
    programs must not rely on a maximum depth greater than 17 (changed to
1024 in C++0x).

Though this is not a compliance issue, but IMHO, it would be nice if clang
could follow suit.

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.

> 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.

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).

Best,
- kenneth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140109/48ea576e/attachment.html>