Re: r261774 - Bail on compilation as soon as a job fails.

2017-05-15 Thread Steven Wu via cfe-commits
> On May 15, 2017, at 3:03 PM, Nico Weber wrote: > > test/Driver/cl-pch-errorhandling.cpp tests the clang-cl pch bits. 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

Re: r261774 - Bail on compilation as soon as a job fails.

2017-05-15 Thread Nico Weber via cfe-commits
test/Driver/cl-pch-errorhandling.cpp tests the clang-cl pch bits. On Mon, May 15, 2017 at 5:42 PM, Steven Wu 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

Re: r261774 - Bail on compilation as soon as a job fails.

2017-05-15 Thread Justin Lebar via cfe-commits
> 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 outp

Re: r261774 - Bail on compilation as soon as a job fails.

2017-05-15 Thread Steven Wu via cfe-commits
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 wrote: > > r262420 landed in a way adapted to Ju

Re: r261774 - Bail on compilation as soon as a job fails.

2017-05-15 Thread Nico Weber via cfe-commits
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 wrote: > Hi Nico > > Now that r262420 is

Re: r261774 - Bail on compilation as soon as a job fails.

2017-05-15 Thread Steven Wu via cfe-commits
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 > wrote: > > On Sat, Apr 22, 2017 at 8:40 PM, Duncan P. N. Exon Smith via cfe-commits > ma

Re: r261774 - Bail on compilation as soon as a job fails.

2017-04-22 Thread Nico Weber via cfe-commits
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/96999

Re: r261774 - Bail on compilation as soon as a job fails.

2017-04-22 Thread Duncan P. N. Exon Smith via cfe-commits
[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 com

Re: r261774 - Bail on compilation as soon as a job fails.

2016-02-29 Thread Justin Lebar via cfe-commits
I think the reason this becomes tricky is that you can reuse Action nodes for multiple invocations of cc1 (or your favorite tool). We do this on macos with bindarch for universal binaries. So you can't necessarily point to one CompilationAction node and say "*that* failed with an error", with no

Re: r261774 - Bail on compilation as soon as a job fails.

2016-02-29 Thread David Blaikie via cfe-commits
On Mon, Feb 29, 2016 at 11:19 AM, Justin Lebar via cfe-commits < cfe-commits@lists.llvm.org> wrote: > > Can you expand on this? The idea is that those implicit deps are in > addition to regular dependencies, not a replacement. > > Sure. > > What I was trying to say is, suppose you have two CUDA de

Re: r261774 - Bail on compilation as soon as a job fails.

2016-02-29 Thread Justin Lebar via cfe-commits
> Can you expand on this? The idea is that those implicit deps are in addition > to regular dependencies, not a replacement. Sure. What I was trying to say is, suppose you have two CUDA device compilations. You want device compilation B to bail if device compilation A fails. So what are the im

Re: r261774 - Bail on compilation as soon as a job fails.

2016-02-29 Thread Nico Weber via cfe-commits
On Sun, Feb 28, 2016 at 3:40 PM, Justin Lebar wrote: > On Sun, Feb 28, 2016 at 1:46 PM, Nico Weber wrote: > > Do you think something like the implicit inputs thing in > > http://reviews.llvm.org/D17695 could work for you as well, instead of > this > > patch? > > Having read just the patch descri

Re: r261774 - Bail on compilation as soon as a job fails.

2016-02-28 Thread Justin Lebar via cfe-commits
On Sun, Feb 28, 2016 at 1:46 PM, Nico Weber wrote: > Do you think something like the implicit inputs thing in > http://reviews.llvm.org/D17695 could work for you as well, instead of this > patch? Having read just the patch description, I think it would be workable, although it might not be partic

Re: r261774 - Bail on compilation as soon as a job fails.

2016-02-28 Thread Nico Weber via cfe-commits
Do you think something like the implicit inputs thing in http://reviews.llvm.org/D17695 could work for you as well, instead of this patch? Then we don't have to forever promise to compile all .cc input files serially. On Wed, Feb 24, 2016 at 4:49 PM, Justin Lebar via cfe-commits < cfe-commits@list

r261774 - Bail on compilation as soon as a job fails.

2016-02-24 Thread Justin Lebar via cfe-commits
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 o