Copying and Filling Zero Bytes

[bashbaug]

Specification Version

SYCL 2020 (Revision 9)

Section Number(s)

https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:explicitmemory

Issue Description

Found while working on the "unified SVM" OpenCL extension: KhronosGroup/OpenCL-Docs#1282:

https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:explicitmemory

Is "zero bytes" valid for all of the "SYCL functions for explicit memory operations" - things like copy(), fill(), memcpy(), memset()?

If a size of zero is valid, is any validation done on any of the pointer arguments, or may they be NULL or otherwise bogus?

Note: I took a quick pass through the SYCL CTS and I don't think any of these scenarios are tested, so if they are valid then we may want CTS enhancements as well.

Thanks!

Code Example (Optional)

No response

[TApplencourt]

Is "zero bytes" valid for all of the "SYCL functions for explicit memory operations" - things like copy(), fill(), memcpy(), memset()?

I would hope so!

If a size of zero is valid, is any validation done on any of the pointer arguments, or may they be NULL or otherwise bogus?

I would assume "ok to be totally bogus | no check" as nobody will touch access those pointer. Aka even if you do memcopy(a,b,0) where, a, b are in different context, I'm ok with no error throw.

My argument is the same as "used mean touching" that we use for non supported data-type. It's ok to have double *a on a struct on device that don't support double if you are not using this members.

But I'm an ugly HPC guy, SC people may have different feeling about it

[abagusetty]

I stumbled upon this case a few weeks ago, still fresh in mem.

When compared to C++, it seems to allow to zero-bytes as NO-OP. Not sure if the language in SYCL spec is specific about tagging this as a NO-OP or a UB. Also from a quick read here, validation of pointers are not required

Where an argument declared as size_t n specifies the length of the array for a function, n can have
the value zero on a call to that function. Unless explicitly stated otherwise in the description of a
particular function in this subclause, pointer arguments on such a call shall still have valid values, as
described in 7.1.4. On such a call, a function that locates a character finds no occurrence, a function
that compares two character sequences returns zero, and a function that copies characters copies
zero characters.

[bashbaug]

Yeah, I found that too, but I wasn't quite sure what to make of:

Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4.

Does this mean that the pointers should not be NULL or otherwise bogus?

[tomdeakin]

The WG discussed this. We agree that a copy of zero bytes should be allowed (and same for fill, etc). We also agree that in this case, pointers can be NULL/nullptr.
Next steps:

• CTS to check this.
• Wording clarification, including require non-overlapping.