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.
Details
- Reviewers
echristo bogner - Commits
- 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.
rL245304: We shouldn't need to pass -fno-strict-aliasing when building clang with clang.
Diff Detail
- Repository
- rL LLVM
Event Timeline
This is fine, but would you mind moving it to the cmake and autoconf checks
respectively? Probably near the warning checks where we already check for
compiler.
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)
echristo,
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.
Thoughts?
Makefile | ||
---|---|---|
68 ↗ | (On Diff #32163) | The first of these is marked fixed, the second has a "works on trunk" comment (from 2010). Maybe this isn't needed with gcc anymore either? |
- 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.
Sure I guess. I'm still not sure why we can't do this in the configure side of things, but I don't really care that much for now.