- User Since
- Jan 8 2015, 1:53 PM (157 w, 5 d)
@bkramer Can you take a look at the patch?
Looks OK to me. That said, I have little clue about DWARF, so I'll defer to echristo@ as it's his domain.
Fri, Jan 12
Mon, Jan 8
Fri, Jan 5
Never mind. There must be something else going on in the case where I've discovered the crash. the test case in this patch does not really reproduce the issue by itself. :-(
Thu, Jan 4
Dotting the 'i's on the questions that were not replied to directly.
Tue, Jan 2
Thu, Dec 21
Added to my todo list. There are few more gaps that I want to test in order to make sure we don't regress on compatibility with older CUDA versions while changing these wrappers.
Dec 11 2017
Dec 8 2017
Ideally the tests should be hermetic and should use mock CUDA installation that comes with the tests. E.g. --cuda-path=%S/Inputs/CUDA/usr/local/cuda
Dec 6 2017
Dec 5 2017
I'll defer to @echristo for the final approval.
LGTM in general. Can you think of a way to verify new functionality? It looks like we may have to wait until some target starts using it.
Nov 30 2017
Nov 29 2017
There must be some truth in the saying "naming is one of the hardest problems in computer science". :-/
Nov 28 2017
Nov 27 2017
I'm reluctant to add a distribution-specific search path unconditionally.
Nov 22 2017
@rjmccall : are you OK with this approach? If VLA is not supported by the target, CUDA is handled as a special case so it can emit deferred diag, OpenMP reports an error only if shouldDiagnoseTargetSupportFromOpenMP() allows it, and everything else does so unconditionally.
Nov 21 2017
Updated CUDA tests
Updated to partially address rjmccall@ comments.
Nov 20 2017
Updates CUDA's VLA test to use nvptx triple.
Folded OpenCL check under if (T->isVariableArrayType())
Looks OK to me. I'll defer to gtbercea@ for the final stamp.
Nov 17 2017
Nov 16 2017
Nov 14 2017
Landed in r318173
Nov 9 2017
LGTM for CUDA-related functionality & tests. Thank you for the patch!
Nov 8 2017
Nov 7 2017
Nov 6 2017
Nov 2 2017
Oct 25 2017
Oct 24 2017
Oct 23 2017
The point was that we have two error messages for one problem -- this CUDA version does not support this GPU. The new message you've added (CUDA9, sm20) has to be rather verbose in order to be correct as it must deal with the possibility of either of the relevant arguments being the source of the error. The other end of the problem (CUDA<9, sm_70) should ideally be phrased similarly. But why do we need both? IMO both cases could be reported more consistently with a single message similar to the one you've added -- "CUDA version X does not support compiling for GPU arch Y. Use --cuda-gpu-arch to specify a different GPU arch, use --cuda-path to specify a different CUDA install, or pass --no-cuda-version-check."
Addressed Justin's comments.
Oct 17 2017
Justin is right. I completely forgot about this. :-/
Hal offered possible solution: https://reviews.llvm.org/D17738#661115