> I don't know if that approach could be used for CUDA. Justin should reply > here.
Sorry, I am not sure what the question is. Compiling a single CUDA file invokes clang -cc1 multiple times: Once for the host (i.e. CPU), and once for every GPU architecture we're targeting. We then take the output of all of these invocations of clang -cc1 and glom them together into a single object file. I think the correct thing to do is to treat CUDA compilation of a single file as a unit and stop compiling *for that file* as soon as one of the constituent compilations fails. But we can continue compiling any other files that were listed on the same command line. On Mon, May 15, 2017 at 2:42 PM, Steven Wu <steve...@apple.com> wrote: > 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? > > Steven > > On May 15, 2017, at 12:42 PM, Nico Weber <tha...@chromium.org> wrote: > > r262420 landed in a way adapted to Justin's change. An earlier version of > https://reviews.llvm.org/D17695 had a different approach. I don't know if > that approach could be used for CUDA. Justin should reply here. > > On Mon, May 15, 2017 at 1:32 PM, Steven Wu <steve...@apple.com> wrote: >> >> Hi Nico >> >> Now that r262420 is landed. Is there any plan to move CUDA to the new >> approach so we can fix the UNIX conformance test? >> >> Thanks >> >> Steven >> >> On Apr 22, 2017, at 8:08 PM, Nico Weber via cfe-commits >> <cfe-commits@lists.llvm.org> wrote: >> >> On Sat, Apr 22, 2017 at 8:40 PM, Duncan P. N. Exon Smith via cfe-commits >> <cfe-commits@lists.llvm.org> wrote: >>> >>> [Some necromancy here...] >>> >>> This commit effectively reverted r173361 and r173825, breaking UNIX >>> conformance for our c99 wrapper. >>> >>> See: >>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html >>> >>> 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. >>> >>> >>> We had a test, but this commit changed that as well (I suppose it could >>> have been better documented). >>> >>> How easily could this be restricted to only affect CUDA jobs? >> >> >> If this gets reverted, the clang-cl PCH code needs to use the approach in >> https://reviews.llvm.org/D17695 before I rebased that patch over this >> revision here, so that a PCH compilation failure stops the compilation of >> the main TU. >> >>> >>> >>> On Feb 24, 2016, at 13:49, Justin Lebar via cfe-commits >>> <cfe-commits@lists.llvm.org> wrote: >>> >>> Author: jlebar >>> Date: Wed Feb 24 15:49:28 2016 >>> New Revision: 261774 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=261774&view=rev >>> Log: >>> Bail on compilation as soon as a job fails. >>> >>> Summary: >>> (Re-land of r260448, which was reverted in r260522 due to a test failure >>> in Driver/output-file-cleanup.c that only showed up in fresh builds.) >>> >>> Previously we attempted to be smart; if one job failed, we'd run all >>> jobs that didn't depend on the failing job. >>> >>> Problem is, this doesn't work well for e.g. CUDA compilation without >>> -save-temps. In this case, the device-side and host-side Assemble >>> actions (which actually are responsible for preprocess, compile, >>> backend, and assemble, since we're not saving temps) are necessarily >>> distinct. So our clever heuristic doesn't help us, and we repeat every >>> error message once for host and once for each device arch. >>> >>> The main effect of this change, other than fixing CUDA, is that if you >>> pass multiple cc files to one instance of clang and you get a compile >>> error, we'll stop when the first cc1 job fails. >>> >>> Reviewers: echristo >>> >>> Subscribers: cfe-commits, jhen, echristo, tra, rafael >>> >>> Differential Revision: http://reviews.llvm.org/D17217 >>> >>> Modified: >>> cfe/trunk/lib/Driver/Compilation.cpp >>> cfe/trunk/test/Driver/output-file-cleanup.c >>> >>> Modified: cfe/trunk/lib/Driver/Compilation.cpp >>> URL: >>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=261774&r1=261773&r2=261774&view=diff >>> >>> ============================================================================== >>> --- cfe/trunk/lib/Driver/Compilation.cpp (original) >>> +++ cfe/trunk/lib/Driver/Compilation.cpp Wed Feb 24 15:49:28 2016 >>> @@ -163,39 +163,17 @@ int Compilation::ExecuteCommand(const Co >>> return ExecutionFailed ? 1 : Res; >>> } >>> >>> -typedef SmallVectorImpl< std::pair<int, const Command *> > >>> FailingCommandList; >>> - >>> -static bool ActionFailed(const Action *A, >>> - const FailingCommandList &FailingCommands) { >>> - >>> - if (FailingCommands.empty()) >>> - return false; >>> - >>> - for (FailingCommandList::const_iterator CI = FailingCommands.begin(), >>> - CE = FailingCommands.end(); CI != CE; ++CI) >>> - if (A == &(CI->second->getSource())) >>> - return true; >>> - >>> - for (const Action *AI : A->inputs()) >>> - if (ActionFailed(AI, FailingCommands)) >>> - return true; >>> - >>> - return false; >>> -} >>> - >>> -static bool InputsOk(const Command &C, >>> - const FailingCommandList &FailingCommands) { >>> - return !ActionFailed(&C.getSource(), FailingCommands); >>> -} >>> - >>> -void Compilation::ExecuteJobs(const JobList &Jobs, >>> - FailingCommandList &FailingCommands) const >>> { >>> +void Compilation::ExecuteJobs( >>> + const JobList &Jobs, >>> + SmallVectorImpl<std::pair<int, const Command *>> &FailingCommands) >>> const { >>> for (const auto &Job : Jobs) { >>> - if (!InputsOk(Job, FailingCommands)) >>> - continue; >>> const Command *FailingCommand = nullptr; >>> - if (int Res = ExecuteCommand(Job, FailingCommand)) >>> + if (int Res = ExecuteCommand(Job, FailingCommand)) { >>> FailingCommands.push_back(std::make_pair(Res, FailingCommand)); >>> + // Bail as soon as one command fails, so we don't output duplicate >>> error >>> + // messages if we die on e.g. the same file. >>> + return; >>> + } >>> } >>> } >>> >>> >>> Modified: cfe/trunk/test/Driver/output-file-cleanup.c >>> URL: >>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/output-file-cleanup.c?rev=261774&r1=261773&r2=261774&view=diff >>> >>> ============================================================================== >>> --- cfe/trunk/test/Driver/output-file-cleanup.c (original) >>> +++ cfe/trunk/test/Driver/output-file-cleanup.c Wed Feb 24 15:49:28 2016 >>> @@ -38,6 +38,9 @@ invalid C code >>> // RUN: test -f %t1.s >>> // RUN: test ! -f %t2.s >>> >>> +// When given multiple .c files to compile, clang compiles them in order >>> until >>> +// it hits an error, at which point it stops. >>> +// >>> // RUN: touch %t1.c >>> // RUN: echo "invalid C code" > %t2.c >>> // RUN: touch %t3.c >>> @@ -46,6 +49,6 @@ invalid C code >>> // RUN: cd %T && not %clang -S %t1.c %t2.c %t3.c %t4.c %t5.c >>> // RUN: test -f %t1.s >>> // RUN: test ! -f %t2.s >>> -// RUN: test -f %t3.s >>> +// RUN: test ! -f %t3.s >>> // RUN: test ! -f %t4.s >>> -// RUN: test -f %t5.s >>> +// RUN: test ! -f %t5.s >>> >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> cfe-commits@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >>> >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> cfe-commits@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >> >> _______________________________________________ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> >> > > _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
