No, there was no intention to change behavior. But could you provide more details on this?<br><br><div class="gmail_quote">On Wed, Aug 29, 2012 at 3:41 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</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 Tue, Aug 28, 2012 at 5:20 PM, Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>> wrote:<br>

> Author: alexfh<br>
> Date: Tue Aug 28 19:20:03 2012<br>
> New Revision: 162810<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=162810&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=162810&view=rev</a><br>
> Log:<br>
> Keep history of macro definitions and #undefs<br>
><br>
> Summary:<br>
> Summary: Keep history of macro definitions and #undefs with corresponding source locations, so that we can later find out all macros active in a specified source location. We don't save the history in PCH (no need currently). Memory overhead is about sizeof(void*)*3*<number of macro definitions and #undefs>+<in-memory size of all #undef'd macros><br>

><br>
> I've run a test on a file composed of 109 .h files from boost 1.49 on x86-64 linux.<br>
> Stats before this patch:<br>
> *** Preprocessor Stats:<br>
> 73222 directives found:<br>
>   19171 #define.<br>
>   4345 #undef.<br>
>   #include/#include_next/#import:<br>
>     5233 source files entered.<br>
>     27 max include stack depth<br>
>   19210 #if/#ifndef/#ifdef.<br>
>   2384 #else/#elif.<br>
>   6891 #endif.<br>
>   408 #pragma.<br>
> 14466 #if/#ifndef#ifdef regions skipped<br>
> 80023/451669/1270 obj/fn/builtin macros expanded, 85724 on the fast path.<br>
> 127145 token paste (##) operations performed, 11008 on the fast path.<br>
><br>
> Preprocessor Memory: 5874615B total<br>
>   BumpPtr: 4399104<br>
>   Macro Expanded Tokens: 417768<br>
>   Predefines Buffer: 8135<br>
>   Macros: 1048576<br>
>   #pragma push_macro Info: 0<br>
>   Poison Reasons: 1024<br>
>   Comment Handlers: 8<br>
><br>
> Stats with this patch:<br>
> ...<br>
> Preprocessor Memory: 7541687B total<br>
>   BumpPtr: 6066176<br>
>   Macro Expanded Tokens: 417768<br>
>   Predefines Buffer: 8135<br>
>   Macros: 1048576<br>
>   #pragma push_macro Info: 0<br>
>   Poison Reasons: 1024<br>
>   Comment Handlers: 8<br>
><br>
> In my test increase in memory usage is about 1.7Mb, which is ~28% of initial preprocessor's memory usage and about 0.8% of clang's total VMM allocation.<br>
><br>
> As for CPU overhead, it should only be noticeable when iterating over all macros, and should mostly consist of couple extra dereferences and one comparison per macro + skipping of #undef'd macros. It's less trivial to measure, though, as the preprocessor consumes a very small fraction of compilation time.<br>

<br>
</div></div>This patch causes clang's behavior to change on<br>
<a href="http://llvm.org/viewvc/llvm-project/clang-tests/trunk/gcc-4_2-testsuite/src/gcc.dg/cpp/mac-dir-1.c?view=markup" target="_blank">http://llvm.org/viewvc/llvm-project/clang-tests/trunk/gcc-4_2-testsuite/src/gcc.dg/cpp/mac-dir-1.c?view=markup</a><br>

; is this intentional?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Eli<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div><font color="#666666"><span style="border-top-width:2px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-right-style:solid;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(213,15,37);border-right-color:rgb(213,15,37);border-bottom-color:rgb(213,15,37);border-left-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Alexander Kornienko |</span><span style="border-top-width:2px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-right-style:solid;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(51,105,232);border-right-color:rgb(51,105,232);border-bottom-color:rgb(51,105,232);border-left-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Software Engineer |</span></font><span style="border-top-width:2px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-right-style:solid;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(0,153,57);border-right-color:rgb(0,153,57);border-bottom-color:rgb(0,153,57);border-left-color:rgb(0,153,57);padding-top:2px;margin-top:2px"><font color="#666666"> </font><a href="mailto:alexfh@google.com" style="color:rgb(17,85,204)" target="_blank">alexfh@google.com</a> |</span><span style="border-top-width:2px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-right-style:solid;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(238,178,17);border-right-color:rgb(238,178,17);border-bottom-color:rgb(238,178,17);border-left-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a value="+35315435283" style="color:rgb(17,85,204)">+49 151 221 77 957</a></span></div>
</div><div><font color="#666666"><span style="background-color:rgb(255,255,255);font-family:Arial,Verdana,sans-serif">Google Germany GmbH | </span><span style="background-color:rgb(255,255,255);font-family:Arial,Verdana,sans-serif">Dienerstr. 12 | </span><span style="background-color:rgb(255,255,255);font-family:Arial,Verdana,sans-serif">80331 München</span></font></div>
<br>