fhahn wrote: > What are the chances that this will exploit undefined behavior in existing > user code in ways that will make upgrading to the latest Clang more difficult > because of the perception of "miscompiles?" If this is a likely scenario for > users to hit, do other tools like UBSan (etc) help users to find and fix the > issues? >
As @jcranmer-intel mentioned, there is work on a type sanitizer and there are multiple people interested in making improvements to it. Hopefully we will be able to get an initial version in `main` soon. At the moment, the instrumentation is very expensive and there are some false positives I believe, which limits the usefulness for now. However the existing `-fno-pointer-tbaa` should make it relatively easy for our users to check if a mis-compile is due to the new pointer TBAA metadata (which would imply a strict alias violation in the code or bug in an optimization). It might be worth calling this out in the `Potentially Breaking Changes` section? Given that cutting the release branch is still ~2 months away, I am hoping that enabling this now we will get this exposed to a large number of users before going in the release candidate phase, which should give us a good amount of signal if this is going to be disruptive to a larger number of users. If that's the case, there would be plenty of time to restore to original behavior in time for the Clang 20 release. Another thing to note is that GCC (and I think other commercial compilers) already use this information in their optimizers, so it is probably likely that users of those compilers would already have any existing violations exposed. https://github.com/llvm/llvm-project/pull/117244 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
