<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Nov 10, 2015, at 2:53 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 10, 2015 at 10:11 AM, Jason Haslam via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">There’s a test file in boost at libs/preprocessor/doc/examples/delay.c that causes clang to quickly consume large amounts of memory. Has anybody seen this before? Is there some sort of workaround (like maybe a flag to limit macro expansion depth)? I couldn’t find an issue in the bug tracker.<br class=""></blockquote><div class=""><br class=""></div><div class="">From that file:</div><div class=""><pre style="margin: 1.5em; padding: 0.5em; font-size: 11.4px; border: 1px solid rgb(204, 204, 204); overflow: auto; clear: left;" class=""># /* The time complexity of DELAY(N) is O(2^N).
# *
# * Handy when recompiles are too fast to take a coffee break. :)
# *
# * Template metaprogramming can be used for implementing similar
# * delays. Unfortunately template instantiation consumes memory,
# * therefore compilers usually fail to fully compile long template
# * based delays, because they run out of memory.
# *
# * On many compilers (e.g. g++, MSVC++), this macro takes only a
# * small amount of memory to preprocess. On some compilers (e.g.
# * MWCW), however, this macro seems to consume huge amounts of
# * memory.
</pre></div><div class="">The "problem" is likely to be that we're keeping track of all the macro expansions performed by this ridiculous code, so this will use 2^N memory as well as 2^N time. We don't have any way to turn that off. If you file a bug on this, it's likely to be resolved as invalid unless you can provide a good reason for why we should care about code that is deliberately trying to break the compiler.</div></div></div></div>
</div></blockquote></div><br class=""></div><div class="">Okay, thanks. I don’t necessarily care about this code or expect anything reasonable to happen. The issue arises when users blindly try to slurp up and analyze everything in a directory. The outcome isn’t very friendly (especially on Windows).<div class=""><br class=""></div><div class="">Jason</div></div><div class=""><br class=""></div></body></html>