<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><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><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><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><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" <andyg1001@hotmail.co.uk>:</div><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>Regards,<br /> Andrei Serebro</div><div>tel. +79111758381</div><div>š</div>