The code comments in the Makefile indicate this was put in place to support issues when building clang with GCC. Today clang's strict aliasing works, so we shouldn't pass -fno-strict-aliasing when building with clang.
- rL245304: We shouldn't need to pass -fno-strict-aliasing when building clang with clang.
rGc5635a6af7c6: We shouldn't need to pass -fno-strict-aliasing when building clang with clang.
rC245304: We shouldn't need to pass -fno-strict-aliasing when building clang with clang.
Have you tested this? I assume there are strict aliasing violations in
Clang/LLVM if we've had this turned on for a while.
(does strict aliasing still have the special case for enum type punning?
Becaues I've certainly seen (& fixed) that in a few places in Clang/LLVM)
I can move the makefile check to the autoconf check, but I think setting the flags should stay in the clang CMakeLists/Makefile otherwise it will change behavior. Today we only enable this flag for the clang subdirectory, not all of LLVM.
- Adapting to r245255 which exposes a variable in autoconf for which compiler you are building with.
- Updated the CMake to be more CMake-y
Note: This has been tested by running a check on a stage2 clang built with asan and ubsan.