[llvm-bugs] [Bug 31041] New: Unhelpful error and inconsistent behavior with "clang -E -o" and "clang -S -o" when compiling CUDA code

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=31041

            Bug ID: 31041
           Summary: Unhelpful error and inconsistent behavior with "clang
                    -E -o" and "clang -S -o" when compiling CUDA code
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: CUDA
          Assignee: unassignedclangbugs at nondot.org
          Reporter: justin.lebar at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Without -o, -E does host compilation and prints to stdout:

$ echo 'XXX __CUDA_ARCH__' | llvm-run clang++ -E -x cuda - | grep XXX
XXX __CUDA_ARCH__

(That the __CUDA_ARCH__ macro is not defined indicates that the preprocessed
source is host code, rather than device code.)

But with -o, we raise a confusing error:
$ echo | llvm-run clang++ -E -x cuda - -o -
clang-4.0: error: cannot specify -o when generating multiple output files

The same thing happens with -S, except that -S outputs *device* assembly:

$ echo | llvm-run clang++ -S -x cuda -
$ cat -- '--cuda-nvptx64-nvidia-cuda-sm_20.s' 
//
// Generated by LLVM NVPTX Back-End
//
[...]

With -o, we raise the same confusing error:
$ echo | llvm-run clang++ -E -x cuda - -o -
clang-4.0: error: cannot specify -o when generating multiple output files


I can see two ways to rationalize our behavior:

1) Require --cuda-device-only or --cuda-host-only with -E and -S (with and
without -o), and improve the error message to mention these flags.

2) Default -E and -S to either host or device and make things work the same
with -o.

I kind of lean towards (1), but maybe that would break people?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161117/d13e3279/attachment.html>