[PATCH] D39502: [Driver] Make clang/cc conforms to UNIX standard

Artem Belevich via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 6 17:12:06 PST 2017

tra added inline comments.

Comment at: test/Driver/cuda-bail-out.cu:47
+// CHECK-HOST-ERROR: Error during compilation for host
+// CHECK-HOST-ERROR-NOT: Error during compilation for sm_35
steven_wu wrote:
> tra wrote:
> > To make it more robust, I'd add another copy of the last line before CHECK-HOST-ERROR: so it would catch device-side errors if they were to happen ahead of the host.
> > 
> > Generally speaking, expected behavior is "I want to see an error from one compilation only". We don't really care which CUDA compilation phase produces it. Perhaps all we need in all test cases is:
> > 
> > ```
> > CHECK: Error during compilation
> > CHECK-NOT:  Error during compilation
> > ```
> > 
> > This way we don't need to depend on specific phase order.
> That will be a design choice for CUDA driver. I have no preference going either direction. Just let me know so I will update the test case.
> Speaking of "-fsyntax-only", this is another interesting behavior of clang cuda driver:
> ```
> $ clang -x cuda /dev/null -x c /dev/null -ccc-print-phases
> 14: input, "/dev/null", c, (host-cuda)
> $ clang -fsyntax-only -x cuda /dev/null -x c /dev/null -ccc-print-phases
> 9: input, "/dev/null", c
> ```
> So depending on if -fsyntax-only is used or not, the c language part can be either offloading or not offloading.
> This is a corner case that the driver behavior will change after this patch.
OK. Let's just check for one error only. 

As for the second, it is, IMO a problem. The file after ```-x c```  should have been treated as plain C input, regardless of -fsyntax-only.  It's reproducible in clean clang tree, so it's not due to this patch. 


More information about the cfe-commits mailing list