beanz added a comment. There are basically two solutions being debated. Either make `-fsanitize=...` bypass `-nostdlib` `-nodefaultlibs` or support a flag that explicitly bypasses it.
Personally I think the flag is probably the better way to go because it is more explicit, and has less implied behavior. If we go with this solution I will add a check to libcxx to detect if the compiler supports the flag and add it to sanitizer builds before committing the support to clang. This should prevent any breakages. @kubabrecka, I can understand where you're coming from about the option starting with `-fsanitize`, but I disagree for two reasons. First, I think that it is more important for the option to be concise and clear about what it means, and `-flink-sanitizer-runtimes` seems pretty clear to me. Second, the existing `-fsanitize` options all refer to the compiler inserted runtime checks, where as this refers to the driver behavior, so I think there is a difference between the intention of the flags that justifies them not conforming to the same format. I also have a small problem with @rsmith's point about `-fsanitize` being an explicit request when linking. I get very nervous about the idea of a flag having different meaning when compiling from when linking. While I understand that it doesn't make sense for `-fsanitize` options to not imply linking the runtimes, I think there is a good argument that they're not an explicit request for the runtime libraries. Either way I don't really care which set of patches we go with. At this point the current diff has a functional `-flink-sanitizer-runtimes` flag supported across all drivers, and the original patch modified the Darwin behavior to match FreeBSD and GNUTools. Thoughts anyone? https://reviews.llvm.org/D24048 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits