-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification of implicit conversion requirements #12
Comments
Oh, and I doubt it matters, but I do have #11 merged |
Disregard this issue, getting rid of the default argument solved it. Bizarre, that might be something you care about later, but this is an avoidable issue. To clarify, moving from
to
Solved the bug |
Interesting, I hadn't run into this before. Because kernels are launched via function pointers, I don't believe it's possible to support default arguments. (Unfortunately there's also no easy way to sanity-check the number of arguments). |
That's a little disconcerting, I made kernels with default arguments that
were working if they had one non default argument, but maybe that's just
luck. Oh well, works now.
…On Mar 8, 2018 6:26 PM, "Ben Barsdell" ***@***.***> wrote:
Interesting, I hadn't run into this before. Because kernels are launched
via function pointers, I don't believe it's possible to support default
arguments. (Unfortunately there's also no easy way to sanity-check the
number of arguments).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#12 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEBlycHl6bePGujNL9eJeds8jXcETDG0ks5tcehFgaJpZM4SjnBh>
.
|
Hey folks,
Sorry for the bug a day pace, you just made too useful a product. This bug is the one I'm iffiest about filing, if nothing immediately pops out at you let me know and I'll try to get you a reproducer, it's 100% possible this is on our side.
I'm reading this, which mentions implicit conversions and variadic packs likely resulting in a segfault. I'm seeing such a segfault, though my stack trace goes through this version of launch, which I believe it's supposed to
I can generate one of two functions
Or I can elide specialization as a constant
The launch happens a little like
From that, I successfully create a program, instantiation,...,launcher. I'm invoking the launcher with an "invoke" pattern, I'm packing my args as a tuple and then calling camp::invoke (a lot like std::apply, but more nvcc friendly). The first path, in which we have two real arguments being passed, crashes. The second succeeds. An equivalent operation piped through Cling seems to work.
Any experience with expanding variadic packs causing you grief? Again, if nothing jumps out, I'll drill down myself a bit.
Thanks!
The text was updated successfully, but these errors were encountered: