<div dir="rtl"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">After your patch, you can run all clang regresion tests with "ninja check-clang".</div><div dir="ltr">Passing these would be a good start.</div><div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2016-06-02 11:59 GMT+03:00 Андрей Серебро <span dir="ltr"><<a href="mailto:andy.silv@yandex.ru" target="_blank">andy.silv@yandex.ru</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi,</div><div> </div><div>Yep, I have noticed several problems with the patch after I have sent it, it's my bad, really: first was with variadic macos, second there was an erroneous ## processing, and also now I'm experiencing some problems with compiling Boost 1.61. </div><div>Currently I put a gap for the first problem, so that variadics are just not cached and so expanded in a standard way.</div><div>The second I guess was fixed, now I'm struggling with the third one.</div><span class=""><div> </div><div><blockquote type="cite"><p>However, I am unable to get your patch to work at all. It seems to totally <br>garble the macro expansion, even on simple expansions. And the test-suite <br>produces over 200 unexpected fails.</p></blockquote></div></span><div>That's interesting. Simple samples should definitely work fine (in case there were no variadics). You can share pieces that cause bad behavior, I will try to understand whats wrong with them (probably, it's about that errors with ##).</div><div>Unexpeccted failures I guess are fine since llvm uses Lit to check the test results, and this checking consists of pattern matching the output with the one that is expected. Since I have removed SourceLocation information, the output definitely varies from the expected output that uses them. But I will also look at it in case something not connected with locations also breaks the tests. </div><span class=""><div><blockquote type="cite"><p><br>and I see lots of errors relating to supposed redefinitions of macros, when <br>they aren't.</p></blockquote></div></span><div>Can you please attach some code that can reproduce redefinition problems? I hoped I have found all the cases where it happens, however, I could miss something. </div><div>Thanks a lot for the feedback. </div><div> </div><div>02.06.2016, 10:45, "Andy Gibbs" <<a href="mailto:andyg1001@hotmail.co.uk" target="_blank">andyg1001@hotmail.co.uk</a>>:</div><div class="HOEnZb"><div class="h5"><blockquote type="cite"><p>On Mon, May 16, 2016 at 10:46 AM Андрей Серебро wrote:<br><br></p><blockquote> So, I have implemented a prototype. For anyone interested, I attach the<br> patch (I used clang release 38 from github as startup code).<br><br> The prototype consumes 40% less time on preprocessing all boost headers<br> than original clang (780 seconds vs 1330). On real-world source code<br> patched clang seems to be usually faster than original.<br><br> The big problem with it is that it currently doesn't generate proper<br> source locations for expanded tokens. It doesn't affect the final code,<br> but of course it makes diagnostics hard in case of errors. On the other<br> hand, this situation is similar with inline functions debugging: without<br> special flag, debugging will not be that easy.<br><br> I have also measured timings for patched clang and clean clang, but with<br> removed information about expansion locations (for it could happen, that<br> all the profit came from switching off this info). But it turned out,<br> that patched is still 28% faster (1100 seconds vs 780 seconds).<br><br> I think, it may be useful probably to have some flag in clang that allows<br> fast preprocessing, for sometimes profit can reach up to x4 times!<br><br> I'm pretty sure there are some bugs now I haven't yet recognized, so any<br> feedback is highly appreciated.</blockquote><p><br>Hi,<br><br>I came across your post rummaging through the mailing list and I am most <br>interested in it, not least because with minimal effort and an albeit fairly <br>pathological macro expansion, I can make clang crash with the message "Ran <br>out of source locations!" (assert inside SourceLocations.cpp). So anything <br>that will help there will be great.<br><br>However, I am unable to get your patch to work at all. It seems to totally <br>garble the macro expansion, even on simple expansions. And the test-suite <br>produces over 200 unexpected fails. Other problems I see are that it gives <br>an error on the following define (claiming an unterminated function-like <br>macro invocation):<br><br>#define M1(...) M2(__VA_ARGS__<br><br>and I see lots of errors relating to supposed redefinitions of macros, when <br>they aren't.<br><br>Is it possible that you attached an incomplete patch? Do you have a working <br>test-case that I can start with? I would be delighted to test your work <br>further.<br><br>Cheers,<br>Andy<br><br></p></blockquote><div> </div><div> </div></div></div><div class="HOEnZb"><div class="h5"><div>-- </div><div>Regards,<br> Andrei Serebro</div><div>tel. +79111758381</div><div> </div></div></div></blockquote></div><br></div>