-
Notifications
You must be signed in to change notification settings - Fork 769
[WIP] [DO NOT MERGE] add std::span support #3509
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
Conversation
SYCL 2020 makes |
@Pennycook - Yes, it needs to be moved to the sycl namespace and it should check for being available before including this. Thanks for reminding me. |
Signed-off-by: Chris Perkins <[email protected]>
Signed-off-by: Chris Perkins <[email protected]>
Signed-off-by: Chris Perkins <[email protected]>
//===---------------------------------------------------------------------===// | ||
|
||
#ifndef _LIBCPP_SPAN | ||
#define _LIBCPP_SPAN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems the guard should be renamed as well. Otherwise it can guard away original span from libc++ user might want to include.
I've incorporated the feedback. The C++ uplift macro has been merged, so there is a new final PR for the span support here: #3569 I am closing this draft. |
This PR depends upon the C++17 uplift which is not yet merged ( #3447 )
This PR adds std::span support to SYCL, however it is not yet ready to merge. It still needs tests and there are decisions about files and file management.
The files libcxx_span.hpp, libcxx_config.hpp and libcxx_undefmacros.hpp are all copies from Clang libcxx, which is not presently built or used by DPCPP. The original files were named
span
,__config
and__undef_macros
. In the case for libcxx_config.hpp and libcxx_undefmacros.hpp I have only lightly modified them, by converting statements like#include <__config>
to#include "libcxx_config.hpp"
.But libcxx_span has had more changes, such as dropping the private
__wrap_iter
class that LIBCXX defines in its implementation of<iterator>
. I have inserted comments with//CP
wherever I effected a change. Otherwise, I've tried to leave the files untouched - so they are as close to their original LIBCXX counterparts as possible.Questions:
libcxx_span.hpp
etc) or should they be named something else?include/CL/sycl
?#pragma once
but these header files all use the#ifndef X / #define X ... #endif
trick. Any issues there?Anyway, let me know if you have feedback.