-
Notifications
You must be signed in to change notification settings - Fork 156
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
Compiler error when indexing sycl::accessor with dimensions > 1 #127
Comments
Thanks for reporting. There are no unit tests yet to cover this slice API, so it's not yet really expected to work ;) In the meantime, if feasible for your code base, I would propose to index with
|
I'm also running into this issue. It's very convenient for stencil codes to index the access as It's tricky because the return type of this accessor is unspecified in the spec, which is probably sensible as it's an internal implementation detail. Ultimately when everything is specified you'd want this to come out as Equation 4.3, but I'm not totally convinced this is possible. |
So far I have no concerns that it is possible to implement equation 4.3 in that way (I assume this is just the linear id equation, I don't know the equation numbering from the top of my head ;) ). After all, the linear id equation is just the regular linearization equation that C and C++ use for constructs like Is it an acceptable workaround for your stencil code as well to just use |
Sorry, yes that's the linear id equation! Do we not have to worry about the intermediate |
Ah, so you are effectively asking about various implementation choices (compiler vs library). I suppose this could probably also be implemented with some compiler trickery to replace the nested Because of this, the current implementation in hipSYCL (which is not yet working) returns a proxy object from |
Houston, we have a fix! I took some time yesterday evening to implement the idea outlined above in PR #186. |
Fixed by PR #186. |
Thanks!! |
When compiling this code:
For the errors regarding private members, I think adding a templated friend declaration inside the definition of
accessor
is enough:The assigment on line 530 of accessor.hpp also needs to explicitly convert
_buffer_range
into the appropriate type. I'm not sure how to fix the error about the base class initialization, though.The text was updated successfully, but these errors were encountered: