<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 15, 2017, at 3:03 PM, Nico Weber <<a href="mailto:thakis@chromium.org" class="">thakis@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">test/Driver/cl-pch-errorhandling.cpp tests the clang-cl pch bits.<br class=""></div></div></blockquote><div><br class=""></div><div>I don't think reverting r261774 will break any cl-pch tests (didn't try windows). That is why I wondering if there is any test case for CUDA so I don't break them when fixing UNIX conformance.</div><div><br class=""></div><div>Steven</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, May 15, 2017 at 5:42 PM, Steven Wu <span dir="ltr" class=""><<a href="mailto:stevenwu@apple.com" target="_blank" class="">stevenwu@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">The other option is to make this behavior configurable so that clang on UNIX behaves differently than clang-cl or CUDA. I am not sure what problem CUDA is hitting. Is there a test case for that?<span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Steven</div></font></span><div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 15, 2017, at 12:42 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank" class="">thakis@chromium.org</a>> wrote:</div><br class="m_4593077761056388119Apple-interchange-newline"><div class=""><div dir="ltr" class="">r262420 landed in a way adapted to Justin's change. An earlier version of <a href="https://reviews.llvm.org/D17695" target="_blank" class="">https://reviews.llvm.org/<wbr class="">D17695</a> had a different approach. I don't know if that approach could be used for CUDA. Justin should reply here.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, May 15, 2017 at 1:32 PM, Steven Wu <span dir="ltr" class=""><<a href="mailto:stevenwu@apple.com" target="_blank" class="">stevenwu@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi Nico<div class=""><br class=""></div><div class="">Now that r262420 is landed. Is there any plan to move CUDA to the new approach so we can fix the UNIX conformance test?</div><div class=""><br class=""></div><div class="">Thanks</div><span class="m_4593077761056388119HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Steven</div></font></span><div class=""><div class="m_4593077761056388119h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 22, 2017, at 8:08 PM, Nico Weber via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank" class="">cfe-commits@lists.llvm.org</a>> wrote:</div><br class="m_4593077761056388119m_-8010861273421467726Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 22, 2017 at 8:40 PM, Duncan P. N. Exon Smith via cfe-commits <span dir="ltr" class=""><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank" class="">cfe-commits@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">[Some necromancy here...]</div><div class=""><br class=""></div><div class="">This commit effectively reverted r173361 and r173825, breaking UNIX conformance for our c99 wrapper.</div><div class=""><br class=""></div><div class="">See:</div><div class=""><div class=""><a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html" target="_blank" class="">http://pubs.opengroup.org/onli<wbr class="">nepubs/9699919799/utilities/c9<wbr class="">9.html</a></div><div class=""><blockquote type="cite" class="">When c99 encounters a compilation error that causes an object file not to be created, it shall write a diagnostic to standard error and continue to compile other source code operands, but it shall not perform the link phase and it shall return a non-zero exit status.<br class=""></blockquote></div></div><div class=""><br class=""></div><div class="">We had a test, but this commit changed that as well (I suppose it could have been better documented).</div><div class=""><br class=""></div><div class="">How easily could this be restricted to only affect CUDA jobs?</div></div></blockquote><div class=""><br class=""></div><div class="">If this gets reverted, the clang-cl PCH code needs to use the approach in <a href="https://reviews.llvm.org/D17695" target="_blank" class="">https://reviews.llvm.org/D1<wbr class="">7695</a> before I rebased that patch over this revision here, so that a PCH compilation failure stops the compilation of the main TU.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="m_4593077761056388119m_-8010861273421467726gmail-h5"><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 24, 2016, at 13:49, Justin Lebar via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank" class="">cfe-commits@lists.llvm.org</a>> wrote:</div><br class="m_4593077761056388119m_-8010861273421467726gmail-m_-5712697613147138422Apple-interchange-newline"><div class=""><div class="">Author: jlebar<br class="">Date: Wed Feb 24 15:49:28 2016<br class="">New Revision: 261774<br class=""><br class="">URL: <a href="http://llvm.org/viewvc/llvm-project?rev=261774&view=rev" target="_blank" class="">http://llvm.org/viewvc/llvm-pr<wbr class="">oject?rev=261774&view=rev</a><br class="">Log:<br class="">Bail on compilation as soon as a job fails.<br class=""><br class="">Summary:<br class="">(Re-land of r260448, which was reverted in r260522 due to a test failure<br class="">in Driver/output-file-cleanup.c that only showed up in fresh builds.)<br class=""><br class="">Previously we attempted to be smart; if one job failed, we'd run all<br class="">jobs that didn't depend on the failing job.<br class=""><br class="">Problem is, this doesn't work well for e.g. CUDA compilation without<br class="">-save-temps. In this case, the device-side and host-side Assemble<br class="">actions (which actually are responsible for preprocess, compile,<br class="">backend, and assemble, since we're not saving temps) are necessarily<br class="">distinct. So our clever heuristic doesn't help us, and we repeat every<br class="">error message once for host and once for each device arch.<br class=""><br class="">The main effect of this change, other than fixing CUDA, is that if you<br class="">pass multiple cc files to one instance of clang and you get a compile<br class="">error, we'll stop when the first cc1 job fails.<br class=""><br class="">Reviewers: echristo<br class=""><br class="">Subscribers: cfe-commits, jhen, echristo, tra, rafael<br class=""><br class="">Differential Revision: <a href="http://reviews.llvm.org/D17217" target="_blank" class="">http://reviews.llvm.org/D17217</a><br class=""><br class="">Modified:<br class=""> cfe/trunk/lib/Driver/Compil<wbr class="">ation.cpp<br class=""> cfe/trunk/test/Driver/outpu<wbr class="">t-file-cleanup.c<br class=""><br class="">Modified: cfe/trunk/lib/Driver/Compilati<wbr class="">on.cpp<br class="">URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=261774&r1=261773&r2=261774&view=diff" target="_blank" class="">http://llvm.org/viewvc/llvm-pr<wbr class="">oject/cfe/trunk/lib/Driver/Com<wbr class="">pilation.cpp?rev=261774&r1=261<wbr class="">773&r2=261774&view=diff</a><br class="">==============================<wbr class="">==============================<wbr class="">==================<br class="">--- cfe/trunk/lib/Driver/Compilati<wbr class="">on.cpp (original)<br class="">+++ cfe/trunk/lib/Driver/Compilati<wbr class="">on.cpp Wed Feb 24 15:49:28 2016<br class="">@@ -163,39 +163,17 @@ int Compilation::ExecuteCommand(co<wbr class="">nst Co<br class=""> return ExecutionFailed ? 1 : Res;<br class=""> }<br class=""><br class="">-typedef SmallVectorImpl< std::pair<int, const Command *> > FailingCommandList;<br class="">-<br class="">-static bool ActionFailed(const Action *A,<br class="">- const FailingCommandList &FailingCommands) {<br class="">-<br class="">- if (FailingCommands.empty())<br class="">- return false;<br class="">-<br class="">- for (FailingCommandList::const_ite<wbr class="">rator CI = FailingCommands.begin(),<br class="">- CE = FailingCommands.end(); CI != CE; ++CI)<br class="">- if (A == &(CI->second->getSource()))<br class="">- return true;<br class="">-<br class="">- for (const Action *AI : A->inputs())<br class="">- if (ActionFailed(AI, FailingCommands))<br class="">- return true;<br class="">-<br class="">- return false;<br class="">-}<br class="">-<br class="">-static bool InputsOk(const Command &C,<br class="">- const FailingCommandList &FailingCommands) {<br class="">- return !ActionFailed(&C.getSource(), FailingCommands);<br class="">-}<br class="">-<br class="">-void Compilation::ExecuteJobs(const JobList &Jobs,<br class="">- F<wbr class="">ailingCommandList &FailingCommands) const {<br class="">+void Compilation::ExecuteJobs(<br class="">+ const JobList &Jobs,<br class="">+ SmallVectorImpl<std::pair<i<wbr class="">nt, const Command *>> &FailingCommands) const {<br class=""> for (const auto &Job : Jobs) {<br class="">- if (!InputsOk(Job, FailingCommands))<br class="">- continue;<br class=""> const Command *FailingCommand = nullptr;<br class="">- if (int Res = ExecuteCommand(Job, FailingCommand))<br class="">+ if (int Res = ExecuteCommand(Job, FailingCommand)) {<br class=""> FailingCommands.push_bac<wbr class="">k(std::make_pair(Res, FailingCommand));<br class="">+ // Bail as soon as one command fails, so we don't output duplicate error<br class="">+ // messages if we die on e.g. the same file.<br class="">+ return;<br class="">+ }<br class=""> }<br class=""> }<br class=""><br class=""><br class="">Modified: cfe/trunk/test/Driver/output-f<wbr class="">ile-cleanup.c<br class="">URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/output-file-cleanup.c?rev=261774&r1=261773&r2=261774&view=diff" target="_blank" class="">http://llvm.org/viewvc/llvm-pr<wbr class="">oject/cfe/trunk/test/Driver/ou<wbr class="">tput-file-cleanup.c?rev=261774<wbr class="">&r1=261773&r2=261774&view=diff</a><br class="">==============================<wbr class="">==============================<wbr class="">==================<br class="">--- cfe/trunk/test/Driver/output-f<wbr class="">ile-cleanup.c (original)<br class="">+++ cfe/trunk/test/Driver/output-f<wbr class="">ile-cleanup.c Wed Feb 24 15:49:28 2016<br class="">@@ -38,6 +38,9 @@ invalid C code<br class=""> // RUN: test -f %t1.s<br class=""> // RUN: test ! -f %t2.s<br class=""><br class="">+// When given multiple .c files to compile, clang compiles them in order until<br class="">+// it hits an error, at which point it stops.<br class="">+//<br class=""> // RUN: touch %t1.c<br class=""> // RUN: echo "invalid C code" > %t2.c<br class=""> // RUN: touch %t3.c<br class="">@@ -46,6 +49,6 @@ invalid C code<br class=""> // RUN: cd %T && not %clang -S %t1.c %t2.c %t3.c %t4.c %t5.c<br class=""> // RUN: test -f %t1.s<br class=""> // RUN: test ! -f %t2.s<br class="">-// RUN: test -f %t3.s<br class="">+// RUN: test ! -f %t3.s<br class=""> // RUN: test ! -f %t4.s<br class="">-// RUN: test -f %t5.s<br class="">+// RUN: test ! -f %t5.s<br class=""><br class=""><br class="">______________________________<wbr class="">_________________<br class="">cfe-commits mailing list<br class=""><a href="mailto:cfe-commits@lists.llvm.org" target="_blank" class="">cfe-commits@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-commits</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></div><br class="">______________________________<wbr class="">_________________<br class="">
cfe-commits mailing list<br class="">
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank" class="">cfe-commits@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-commits</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
______________________________<wbr class="">_________________<br class="">cfe-commits mailing list<br class=""><a href="mailto:cfe-commits@lists.llvm.org" target="_blank" class="">cfe-commits@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-commits</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>