[SYCL] Add STL wrapper for crtdbg.h and define _CrtDbgReport

[uditagarwal97]

Wrapping around because want to define _CrtDbgReport before crtdbg.h header is included. Defining variable templated _CrtDbgReport overrides the use of variable argument _CrtDbgReport function, that declared in crtdbg.h.

With variable argument _CrtDbgReport, llvm-spirv throws the following error:

UnsupportedVarArgFunction: Variadic functions other than 'printf' are not supported in SPIR-V.

Fixes CMPLRLLVM-66787

[AlexeySachkov]

To me, that does not seem like a reliable solution. We still don't have control over the real <array> content and tomorrow it may start using some new error reporting mechanism which won't be covered by this.

I think that the proper way of not hitting issues like this from uncontrolled STL implementations is stop using them in our device headers.

[aelovikov-intel]

We want to provide as much support for using STL in user's code as possible. Using it ourselves and making fixes like that is the best way to ensure the smoothest user experience possible.

[AlexeySachkov]

We want to provide as much support for using STL in user's code as possible.

Do we document any guarantees anywhere? I'm not aware of any extensions and the core SYCL spec explicitly says that everything that is not documented is not guaranteed to be supported.

What is our plan for cases when MSVC headers are updated in an incompatible way in between our releases?

[aelovikov-intel]

We have https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/C-CXX-StandardLibrary.rst and your argument applies to them as well. MSVC can change their implementation of any of the "documented/supported" APIs at any point.

[AlexeySachkov]

We have https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/C-CXX-StandardLibrary.rst and your argument applies to them as well. MSVC can change their implementation of any of the "documented/supported" APIs at any point.

That is true, but the document explicitly only document a concrete subset of functions and 95% of them are implemented in the library. We do take a similar risk, but it is lower. And we have officially taken it by documenting the support.

Here we are somewhat in the gray area where we don't document the support for std::array, but still try to use it and jump through the hoops to make it work, but what's the point if we don't document it to be supported?

I think that we should either document it to justify those tricks, or just make our implementation more robust by explicitly saying that we won't support that.

[aelovikov-intel]

I think "gray area" is a feature and not a bug :) As for documenting, I'd prefer to do it once we are more confident that it actually works. So maybe implement this, use std::array internally, and if we don't have any bug reports for the next release, then document it as supported (i.e. treat the current state as "experimental").

[AlexeySachkov]

As for documenting, I'd prefer to do it once we are more confident that it actually works.

And how do we ensure that? std::array has 20 different methods, do we use them all in our implementation to ensure that they work?

I still find our approach weird. If we want to support std::array, let's write dedicated tests for it and fix any bugs, but I'm not sure if it worth continue to use it in our own implementation.

[AlexeySachkov]

We want to provide as much support for using STL in user's code as possible. Using it ourselves and making fixes like that is the best way to ensure the smoothest user experience possible.

FYI: #18252

[bader]

@uditagarwal97, I think the comment requires updates too.

// Test to isolate sycl::vec bug due to use of std::array in
// the constructor.