**What enhancement are you suggesting for the Vulkan Loader? Please describe in detail. **
Currently the Vulkan-Loader disables aliasing.
# need to prepend /clang: to compiler arguments when using clang-cl
if (CMAKE_C_COMPILER_ID STREQUAL "Clang" AND "${CMAKE_C_COMPILER_FRONTEND_VARIANT}" MATCHES "MSVC")
target_compile_options(loader_common_options INTERFACE $<$<COMPILE_LANGUAGE::CXX,C>:/clang:-fno-strict-aliasing>)
else()
target_compile_options(loader_common_options INTERFACE $<$<COMPILE_LANGUAGE::CXX,C>:-fno-strict-aliasing>)
endif()
Additional context
I understand the rational. I understand this caused a regression.
However, there is now a type sanitizer that can be added to catch problems with aliasing.
See: https://clang.llvm.org/docs/TypeSanitizer.html
The TypeSanitizer is a detector for strict type aliasing violations. It consists of a compiler instrumentation module and a run-time library. C/C++ has type-based aliasing rules, and LLVM can exploit these for optimizations given the TBAA metadata Clang emits. In general, a pointer of a given type cannot access an object of a different type, with only a few exceptions.
These rules aren’t always apparent to users, which leads to code that violates these rules (e.g. for type punning). This can lead to optimization passes introducing bugs unless the code is build with -fno-strict-aliasing, sacrificing performance.
TypeSanitizer is built to catch when these strict aliasing rules have been violated, helping users find where such bugs originate in their code despite the code looking valid at first glance.
**What enhancement are you suggesting for the Vulkan Loader? Please describe in detail. **
Currently the Vulkan-Loader disables aliasing.
Additional context
I understand the rational. I understand this caused a regression.
However, there is now a type sanitizer that can be added to catch problems with aliasing.
See: https://clang.llvm.org/docs/TypeSanitizer.html