Avoid "statement is unreachable" compile errors in async_reduce.cu test

[dkolsen-pgi]

Test test_async_reduce_allocator_on_then_after in async_reduce.cu has
"KNOWN_FAILURE;" in the middle of a code block. This results in "statement is
unreachable" compiler errors from NVC++ on the following line.

"/proj/cuda/thrust/main/testing/async_reduce.cu", line 978: error: statement is
          unreachable
      ASSERT_EQUAL_QUIET(stream1, f2.stream().native_handle());
      ^
          detected during:
            instantiation of "void unittest::for_each_type<TypeList, Function,
                      T, i>::operator()(U) [with TypeList=NumericTypes,
                      Function=test_async_reduce_allocator_on_then_after,
                      T=char, i=0U, U=size_t]" at line 537 of
                      "/proj/cuda/thrust/main/testing/unittest/testframework.h"
            instantiation of "void VariableUnitTest<TestName, TypeList>::run()
                      [with TestName=test_async_reduce_allocator_on_then_after,
                      TypeList=NumericTypes]"

The compiler error is correct. KNOWN_FAILURE expands to a throw expression,
so everything after it is dead code.

Fix the problem by putting everything after KNOWN_FAILURE in a "#if 0" block.

[alliepiper]

CL 28814105

[alliepiper]

CI looks good. @brycelelbach can you merge this along with the other 1.9.10-1 integrations you're doing today?

[brycelelbach]

I don't think this is the right fix; just move KNOWN_FAILURE to the end of the file instead. Also, this should be fixed by an upcoming PR to not be a known failure.

[dkolsen-pgi]

If KNOWN_FAILURE were moved to the end of the function, then (if I am interpreting the comments in the code correctly), at least one of the tests that follow will fail before the KNOWN_FAILURE is hit. I assume that will mark the test as failed in the test results. I think the proposed fix is the correct one. I don't care whether or not this fix gets into 1.9.10-1; its known to be a test bug, not a compiler bug, so the failure won't hold up anything.

[alliepiper]

@brycelelbach Are you still opposed to this approach, or should I start CI on this PR?

[brycelelbach]

No this will be fixed by #1195

[GPUtester]

Can one of the admins verify this patch?

[brycelelbach]

We decided to just go ahead and merge this workaround now as the timeline for me landing the proper fix is unclear.