<div dir="ltr"><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"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><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"><div>[Some necromancy here...]</div><div><br></div><div>This commit effectively reverted r173361 and r173825, breaking UNIX conformance for our c99 wrapper.</div><div><br></div><div>See:</div><div><div><a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html" target="_blank">http://pubs.opengroup.org/<wbr>onlinepubs/9699919799/<wbr>utilities/c99.html</a></div><div><blockquote type="cite">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></blockquote></div></div><div><br></div><div>We had a test, but this commit changed that as well (I suppose it could have been better documented).</div><div><br></div><div>How easily could this be restricted to only affect CUDA jobs?</div></div></blockquote><div><br></div><div>If this gets reverted, the clang-cl PCH code needs to use the approach in <a href="https://reviews.llvm.org/D17695">https://reviews.llvm.org/D17695</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> </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"><div><div class="gmail-h5"><div><br></div><div><div><blockquote type="cite"><div>On Feb 24, 2016, at 13:49, Justin Lebar via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-5712697613147138422Apple-interchange-newline"><div><div>Author: jlebar<br>Date: Wed Feb 24 15:49:28 2016<br>New Revision: 261774<br><br>URL: <a href="http://llvm.org/viewvc/llvm-project?rev=261774&view=rev" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?rev=261774&view=rev</a><br>Log:<br>Bail on compilation as soon as a job fails.<br><br>Summary:<br>(Re-land of r260448, which was reverted in r260522 due to a test failure<br>in Driver/output-file-cleanup.c that only showed up in fresh builds.)<br><br>Previously we attempted to be smart; if one job failed, we'd run all<br>jobs that didn't depend on the failing job.<br><br>Problem is, this doesn't work well for e.g. CUDA compilation without<br>-save-temps.  In this case, the device-side and host-side Assemble<br>actions (which actually are responsible for preprocess, compile,<br>backend, and assemble, since we're not saving temps) are necessarily<br>distinct.  So our clever heuristic doesn't help us, and we repeat every<br>error message once for host and once for each device arch.<br><br>The main effect of this change, other than fixing CUDA, is that if you<br>pass multiple cc files to one instance of clang and you get a compile<br>error, we'll stop when the first cc1 job fails.<br><br>Reviewers: echristo<br><br>Subscribers: cfe-commits, jhen, echristo, tra, rafael<br><br>Differential Revision: <a href="http://reviews.llvm.org/D17217" target="_blank">http://reviews.llvm.org/D17217</a><br><br>Modified:<br>    cfe/trunk/lib/Driver/<wbr>Compilation.cpp<br>    cfe/trunk/test/Driver/<wbr>output-file-cleanup.c<br><br>Modified: cfe/trunk/lib/Driver/<wbr>Compilation.cpp<br>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">http://llvm.org/viewvc/llvm-<wbr>project/cfe/trunk/lib/Driver/<wbr>Compilation.cpp?rev=261774&r1=<wbr>261773&r2=261774&view=diff</a><br>==============================<wbr>==============================<wbr>==================<br>--- cfe/trunk/lib/Driver/<wbr>Compilation.cpp (original)<br>+++ cfe/trunk/lib/Driver/<wbr>Compilation.cpp Wed Feb 24 15:49:28 2016<br>@@ -163,39 +163,17 @@ int Compilation::ExecuteCommand(<wbr>const Co<br>   return ExecutionFailed ? 1 : Res;<br> }<br><br>-typedef SmallVectorImpl< std::pair<int, const Command *> > FailingCommandList;<br>-<br>-static bool ActionFailed(const Action *A,<br>-                         const FailingCommandList &FailingCommands) {<br>-<br>-  if (FailingCommands.empty())<br>-    return false;<br>-<br>-  for (FailingCommandList::const_<wbr>iterator CI = FailingCommands.begin(),<br>-         CE = FailingCommands.end(); CI != CE; ++CI)<br>-    if (A == &(CI->second->getSource()))<br>-      return true;<br>-<br>-  for (const Action *AI : A->inputs())<br>-    if (ActionFailed(AI, FailingCommands))<br>-      return true;<br>-<br>-  return false;<br>-}<br>-<br>-static bool InputsOk(const Command &C,<br>-                     const FailingCommandList &FailingCommands) {<br>-  return !ActionFailed(&C.getSource(), FailingCommands);<br>-}<br>-<br>-void Compilation::ExecuteJobs(const JobList &Jobs,<br>-                              <wbr>FailingCommandList &FailingCommands) const {<br>+void Compilation::ExecuteJobs(<br>+    const JobList &Jobs,<br>+    SmallVectorImpl<std::pair<<wbr>int, const Command *>> &FailingCommands) const {<br>   for (const auto &Job : Jobs) {<br>-    if (!InputsOk(Job, FailingCommands))<br>-      continue;<br>     const Command *FailingCommand = nullptr;<br>-    if (int Res = ExecuteCommand(Job, FailingCommand))<br>+    if (int Res = ExecuteCommand(Job, FailingCommand)) {<br>       FailingCommands.push_<wbr>back(std::make_pair(Res, FailingCommand));<br>+      // Bail as soon as one command fails, so we don't output duplicate error<br>+      // messages if we die on e.g. the same file.<br>+      return;<br>+    }<br>   }<br> }<br><br><br>Modified: cfe/trunk/test/Driver/output-<wbr>file-cleanup.c<br>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">http://llvm.org/viewvc/llvm-<wbr>project/cfe/trunk/test/Driver/<wbr>output-file-cleanup.c?rev=<wbr>261774&r1=261773&r2=261774&<wbr>view=diff</a><br>==============================<wbr>==============================<wbr>==================<br>--- cfe/trunk/test/Driver/output-<wbr>file-cleanup.c (original)<br>+++ cfe/trunk/test/Driver/output-<wbr>file-cleanup.c Wed Feb 24 15:49:28 2016<br>@@ -38,6 +38,9 @@ invalid C code<br> // RUN: test -f %t1.s<br> // RUN: test ! -f %t2.s<br><br>+// When given multiple .c files to compile, clang compiles them in order until<br>+// it hits an error, at which point it stops.<br>+//<br> // RUN: touch %t1.c<br> // RUN: echo "invalid C code" > %t2.c<br> // RUN: touch %t3.c<br>@@ -46,6 +49,6 @@ invalid C code<br> // RUN: cd %T && not %clang -S %t1.c %t2.c %t3.c %t4.c %t5.c<br> // RUN: test -f %t1.s<br> // RUN: test ! -f %t2.s<br>-// RUN: test -f %t3.s<br>+// RUN: test ! -f %t3.s<br> // RUN: test ! -f %t4.s<br>-// RUN: test -f %t5.s<br>+// RUN: test ! -f %t5.s<br><br><br>______________________________<wbr>_________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br></div></div></blockquote></div><br></div></div></div></div><br>______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div>