Closed aoeftiger closed 3 years ago
A quick dirty fix is to comment out the atomics for cc>=6.0:
$ git diff
diff --git a/sixtracklib/cuda/cuda_tools.h b/sixtracklib/cuda/cuda_tools.h
index 5af22e54..e39c85b0 100644
--- a/sixtracklib/cuda/cuda_tools.h
+++ b/sixtracklib/cuda/cuda_tools.h
@@ -216,7 +216,7 @@ SIXTRL_INLINE SIXTRL_DEVICE_FN void NS(Cuda_collect_status_flag_value)(
if( ( status_flags != SIXTRL_ARCH_DEBUGGING_REGISTER_EMPTY ) &&
( ptr_status_flags != SIXTRL_NULLPTR ) )
{
- #if ( defined( __CUDA_ARCH__ ) && ( __CUDA_ARCH__ >= 350 ) )
+ #if ( defined( __CUDA_ARCH__ ) && ( __CUDA_ARCH__ >= 350 ) && ( __CUDA_ARCH__ < 600 ) )
/* sm_35 or larger defines atomicOr also for
* 64Bit variables -> this is the only clean solution */
::atomicOr( ptr_status_flags, status_flags );
Problem is caused by an inconsistency between host and device side - SIXTRL_UINT64 refers to different types. The commit 6522a17 works-around the issue, we'll remove the inconsistencies before merging with master
@aoeftiger Could you please verify whether the latest changes in PR #132 allow you now to compile for compute capabilities >= 3.5 (especially >= 6.0, as demonstrated in your example)? Thank you!cd
Closing since with the merge of PR #132, this should work now. Please re-open in case the issue persists!
For PR #123 I obtain compilation errors for computing capabilities other than 30 (e.g. 60, or here 75:)