[SYCL][CUDA] Enable CXX standard library funcs for CUDA backend

[hdelan]

This PR allows CXX stdlib funcs to be used for NVPTX backend.

See #6379

llvm-test-suite test: intel/llvm-test-suite#1112

It also adds the compiler flag "-fbundle-no-offload-arch", which allows device code bundles to omit arch information, meaning a bundle with the tag sycl-nvptx64-nvidia-cuda-sm_50 can be bundled with the tag sycl-nvptx64-nvidia-cuda when the flag is enabled. This allows for generic bc bundles for a given backend.

I have not moved the NVPTX complex implementation to libdevice. Let me know if I should do so.

The behaviour of IsMathErrnoDefault() now changes so that -fmath-errno is enabled by default for the CUDA toolchain. This allows libdevice funcs to be used by a similar exploit that the SYCL toolchain uses. If necessary this could be reset once the upstream discussion on NVPTX codegen for llvm.sin and other llvm builtins has been resolved and implemented. See https://discourse.llvm.org/t/nvptx-codegen-for-llvm-sin-and-friends/58170/11?u=jdoerfert

cc @Naghasan @AerialMantis @steffenlarsen @bader @jdoerfert

[hdelan]

ping @jinge90

[jinge90]

ping @jinge90

Hi, @hdelan
The libdevice change looks OK and I have 2 questions:

1. Could you also include related libdevice functions in this PR, they are used to support std::complex in SYCL device programming.
2. For assert support, it seems that we finally rely on CUDA runtime to handle "__assertfail", am I correct?

Thanks very much.

[hdelan]

1. Could you also include  related libdevice functions in this PR, they are used to support std::complex in SYCL device programming.

2. For assert support, it seems that we finally rely on CUDA runtime to handle "__assertfail", am I correct?

Thanks for response.

1. In discussions we have sort of decided that the current approach to std::complex is OK and we don't need to implement std::complex through libdevice. @bader please confirm.
2. Yes this is correct. This specialization is happening in libdevice since in earlier discussions we concluded that assertfail doesn't belong in libclc, where spirv or other builtins are specialized for PTX backend if compiling for that triple.

Let me know if you have any other questions

[jinge90]

OK, thanks for the clarification.

[steffenlarsen]

@jinge90 & @smanna12 - Friendly ping.

[elizabethandrews]

@jinge90 & @smanna12 - Friendly ping.

@smanna12 is OOO for a few weeks. I don't see any FE changes remaining in this PR, so FE approval is not required.