UB fix: new-delete-type-mismatch in ~CodeGenTypes()

[m1kit]

It is undefined behavior to use delete expression on something which was not created with corresponding new expression. Switching to explicit global operator delete() call to match with operator new() call at CGFunctionInfo::create().

This issue is raised by Chromium ClusterFuzz, with ASan enabled. https://crbug.com/410141973

[amaiorano]

Note that Mikihito also created a similar PR in LLVM: llvm/llvm-project#135787

[amaiorano]

I noticed that for Windows builds, the option for sized deallocations was explicitly disabled here, and AFAICT, this is a DXC-specific change. The equivalent flag is not disabled for Clang/GCC (-fno-sized-deallocation), and apparently this flag is enabled by default in Clang builds, so I'm not sure why ASAN isn't tripping on this. Maybe it's a recent addition to ASAN checks, and would fail if DXC is built with a more recent Clang.

In any case, I think we will likely drop this PR because there are other delete calls that would need updating. For Chromium DXC builds, we're going to compile DXC with -fno-sized-deallocation.

[amaiorano]

so I'm not sure why ASAN isn't tripping on this. Maybe it's a recent addition to ASAN checks, and would fail if DXC is built with a more recent Clang.

I modified cmake/modules/HandleLLVMOptions.cmake to add -fsized-deallocation to CMAKE_CXX_FLAGS, and built an ASAN-enabled DXC with Clang 14, and running it against a no-op compute shader ([numthreads(1, 1, 1)] void main() {}) results in the same ASAN failure we're getting in our Chromium build.

As I believe -fsized-deallocation is enabled by default in a later version of Clang, these ASAN failures might already trigger for anyone using a more recent version. If the version on the Azure pipeline is updated, we'll hit it there as well. The simplest fix will be to add -fno-sized-deallocation to CMAKE_CXX_FLAGS on non-Windows builds.

[llvm-beanz]

This prevents calling the destructor, which is maybe working because the destructors are trivial, but we probably shouldn't rely on that.