Added new cl_khr_semaphore tests to verify clCreateSemaphoreWithPropertiesKHR negative results

[shajder]

According to work plan from #1691, new clSemaphoreWrapper introduced to avoid duplication of code

[joshqti]

CL_INVALID_SEMAPHORE_KHR is an error code. Define an invalid property local to the test, this is not correct usage of the macro

[shajder]

CL_INVALID_SEMAPHORE_KHR is an error code. Define an invalid property local to the test, this is not correct usage of the macro

@joshqti thanks, do you have other values on your mind ? Please keep in mind it supposed to be incorrect usage because this is negative test! CL_INVALID_SEMAPHORE_KHR is neither valid name nor property in this case.

[bashbaug]

I think there are two possible errors here:

1. There is an invalid property, which would return CL_INVALID_PROPERTY.
2. The properties do not contain the required properties to create a semaphore (specifically, the semaphore type), which would return CL_INVALID_VALUE.

We should either allow for both error conditions, or we should disambiguate the errors so only CL_INVALID_PROPERTY is returned.

[shajder]

Indeed, after a second look the description of CL_INVALID_PROPERTY and CL_INVALID_VALUE slightly overlaps. I will allow both errors at the moment since correction of spec could be more time consuming. Should I create doc issue ?

[paulfradgley]

Looks good to me.

[kpet]

2024/07/02 teleconference: @shajder Could you rebase/resolve conflicts please?

[nikhiljnv]

Summarizing discussion from memory subgroup call of July 9th 2024.

Per Joshua's comment, using CL_INVALID_SEMAPHORE error code as a property value is confusing.
Ben suggested two options

• Clarify in a comment that CL_INVALID_SEMAPHORE which is an error code is actually an invalid value that can be passed to test error      condition.
  

• Alternatively, pass a different value instead of CL_INVALID_SEMAPHORE to avoid the confusion.
  

[shajder]

Per Joshua's comment, using CL_INVALID_SEMAPHORE error code as a property value is confusing. Ben suggested two options

corrected according to mentioned suggestion

[nikhiljnv]

LGTM.

[nikhiljnv]

Merging as discussed in memory subgroup call on August 6th 2024.