Commit 3cee589 leads to an application error

[colleeneb]

3cee589 broke some code. (Thanks to Aurora CI for catching!)
A reproducer of the issue is below. The change away from always returning hipStreamCaptureStatusNone breaks codes that use patterns like:

    hipStreamWaitEvent(stream2, event, 0);
    hipStreamSynchronize(stream2);

hipStreamWaitEvent changes CaptureStatus_ to hipStreamCaptureStatusActive if it was previously hipStreamCaptureStatusNone. :

chipStar/src/CHIPBindings.cc

Line 3722 in 3cee589

ChipQueue->setCaptureStatus(hipStreamCaptureStatusActive);

hipStreamSynchronize will error out if CaptureStatus_ does not equal hipStreamCaptureStatusNone:

chipStar/src/CHIPBindings.cc

Line 3679 in 3cee589

if (ChipQueue->getCaptureStatus() != hipStreamCaptureStatusNone) {

It worked previously since getCaptureStatus was hard-coded to return hipStreamCaptureStatusNone so hipStreamSynchronize didn't error out.

Reproducer:

#include <hip/hip_runtime.h>
#include <stdio.h>

  #define CHECK(cmd) \
    do { \
      hipError_t e = (cmd); \
      if (e != hipSuccess) { \
        fprintf(stderr, "HIP error %s:%d: %s\n", __FILE__, __LINE__, hipGetErrorString(e)); \
        exit(1); \
      } \
    } while (0)

  int main() {
    hipStream_t stream1, stream2;
    hipEvent_t event;
    CHECK(hipStreamCreate(&stream1));
    CHECK(hipStreamCreate(&stream2));
    CHECK(hipEventCreate(&event));

    CHECK(hipEventRecord(event, stream1));
    CHECK(hipStreamWaitEvent(stream2, event, 0));
    CHECK(hipStreamSynchronize(stream2));

    // cleanup                                                                                                                                                                                                                   
    CHECK(hipDeviceSynchronize());
    CHECK(hipEventDestroy(event));
    CHECK(hipStreamDestroy(stream1));
    CHECK(hipStreamDestroy(stream2));
    return 0;
  }

Compile:

> hipcc t.cpp

Run

> ./a.out
HIP error t.cpp:22: hipErrorUnknown

[colleeneb]

This is the same as the issue fixed in #1235 so closing!