-fsycl disregards `__vectorcall`, breaking parse of `type_traits` on Windows

[MathiasMagnus]

Describe the bug
When targeting any device (non-x86) target on Windows, the __vectorcall attribute on function pointer types is discarded. This causes a type redefinition error when including type_traits from MSVC STL (which pretty much any STL header pulls in), because the implementation of _Is_memfunptr is specialized for every function pointer type with all types of decorators. Because __vectorcall is discarded for device architectures

warning: '__vectorcall' calling convention is not supported for this target [-Wignored-attributes]

the specialization will clash with a previous definition, violating ODR.

To Reproduce
Godbolt

Environment (please complete the following information):

• OS: Windows
• Target device and vendor: HIP (AMD), but likely any non-x86 ISA
• DPC++ version: Intel LLVM at 5995c61

Additional context

ComputeCpp and HIP (amdclang) compilers parse MSVC STL just fine. No amount of -fms-compatibility et al can put the front-end into a mode that preserves this calling convention and would only shriek if codegen would need to occur for the target arch at hand.

[bader]

To Reproduce
Godbolt

• OS: Windows

@MathiasMagnus, did you try the latest DPC++ build on Windows platform? The reproducer uses Linux and according to @premanandrao, the issue is not reproducible on Windows.

[MathiasMagnus]

Latest DPC++ on Windows works fine. This was Intel LLVM I built similarly to how the Intel LLVM image used for the CTS is produced.

[ph0b]

I did hit this issue as well while trying HIP SDK 5.5 on Windows with recent commit fbe7bd1.

[MathiasMagnus]

I have a fix for this as I also had a fix for building on Windows using the HIP SDK, but the recent PI changes shuffled the entire CMake back-end support around and I haven't found the will or incentive to redo the work.

[sarnex]

FYI I hit this same issue trying to enable HIP AMDGPU test build on Windows, I'm going to try to figure it out.

[MathiasMagnus]

@sarnex If you have the time and will to fix this, I have a fork. The most important is the first commit on top of upstream. There is another branch in this fork which tried to resurrect the build system improvements too to make it build on Windows properly, but I ran out of steam. Feel free to draw inspiration from it. (Should you be able to keep attribution where possible is a bonus, but not necessary.)

(These are the kind of hiccups that gravely limits SYCL's applicability. Every single implementation struggles with "trivialities" such as the compiler seeing STL code. ComputeCpp did this too. I haven't been able to get AdaptiveCpp to work on Windows in general. Once @fsfod finishes his blessed work on enabling DYLIB builds on Windows and explicit API annontation, there is hope to get a functioning Debug build on Windows with multiple back-ends to debug why AdaptiveCpp crashes. In general all single-source offload APIs are playing constant catch-up with STL vendors who (rightfully) completely disregard such efforts.)

[sarnex]

Thanks for the reference! Yeah, I'm going to try to fix this (but I don't know how successful I'll be).

My idea for a fix is a bit different than yours, I'm trying to follow what was done for CUDA here, where we use the host toolchain in this case. I'll post any updates here.