Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Functions declarations have HOST_DEVICE_CUDA but definitions #33

Open
ilagunap opened this issue Sep 5, 2018 · 2 comments
Open

Functions declarations have HOST_DEVICE_CUDA but definitions #33

ilagunap opened this issue Sep 5, 2018 · 2 comments

Comments

@ilagunap
Copy link
Member

ilagunap commented Sep 5, 2018

In MC_Particle.hh:
Function declaration of Move_Particle uses HOST_DEVICE_CUDA:

   HOST_DEVICE_CUDA
   void Move_Particle(const DirectionCosine & direction_cosine, const double distance);

but function definition does not:
inline void MC_Particle::Move_Particle( const DirectionCosine &my_direction_cosine, …

In file ParticleVault.hh:
putParticle is declared as HOST_DEVICE_CUDA, but the function definition does not use HOST_DEVICE_CUDA.
invalidateParticle is declared as HOST_DEVICE_CUDA, but the function definition does not use HOST_DEVICE_CUDA.

@bleile1
Copy link
Contributor

bleile1 commented Sep 5, 2018

This is an interesting point. Do you think that the reason it currently compiles/works is due to them being inline functions, negating the compilers need to specify __host__ __device__ ?

I agree that these should match.

@ilagunap
Copy link
Member Author

ilagunap commented Sep 5, 2018

NVCC is silent on this issue, but clang generates an error. Here's the error I get when compiling with clang:

./ParticleVault.hh:175:1: error: __host__ function 'putParticle' cannot overload __host__ __device__ function 'putParticle'
putParticle(MC_Particle particle, int index)
^
./ParticleVault.hh:62:9: note: previous declaration is here
   bool putParticle(MC_Particle particle, int index);

When I add HOST_DEVICE_CUDA to the function definition the error is solved.

I'm not sure why in nvcc it works, but generally speaking clang is more strict on these language/semantics issues.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants