leonardchan added a comment. In https://reviews.llvm.org/D52386#1254437, @rsmith wrote:
> I'm not at all convinced that this is a good thing. There isn't such a thing > as "undefined behavior sanitizer". Rather, there are a whole bunch of > different checks that fall under the same umbrella. This test seems on the > surface to be about as meaningless as `__has_feature(warnings)` would be: > it's useless to ask the question without knowing *which* warnings you're > talking about. But perhaps there's some use case I've overlooked (and your > description of the patch doesn't mention why you want this). What is the use > case you're trying to address with this change? This is part of enabling UBSan for Zircon (the Fuchsia kernel) (https://fuchsia-review.googlesource.com/c/zircon/+/197017). We enable UBSan when building musl libc, but libc is dynamically linked first before sanitizer runtimes, so we need to stub them out in the beginning before the UBSan runtime is linked. This `__has_feature` is there to check if we build with `-fsanitize=undefined` since we only want to define these stubs if libc is built with UBSan. > If we want to change this, you'll also need to update > `getPPTransparentSanitizers` to exclude all the UBSan checks, because it's no > longer the case that those sanitizers only affect code generation. I can update this in another patch. Repository: rL LLVM https://reviews.llvm.org/D52386 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
