gribozavr added a subscriber: gribozavr. gribozavr added a comment. > If a user specifies "-fsanitize=<blah>" I think it is expected that the > sanitizer library would be included on the link line.
I deeply disagree. If the user asks for `-nodefaultlibs`, we should not add any libraries ourselves, because (a) this is what they asked for, and (b) they probably know what they are doing if they are using such a low-level flag. (And they are probably doing something deeply system-specific and they can handle adding more low-level compiler options.) There are issues with the behavior you are proposing. If `-nodefaultlibs` adds some runtime libs, but not others, it is: - confusing, - inconsistent -- users can't predict the behavior of a given set of compiler options. How would you document `-nodefaultlibs` with the semantics that you propose without explicitly explaining this special-case interaction with sanitizers? If you can't, then it means that the design is not the right, intuitive one. - The proposed semantics lead to an immediate feature request for a `-really-nodefaultlibs` option that does not add sanitizer libraries, - The proposed semantics add to an existing mess of the random special-case driver behavior. So the question becomes, what are you trying to do? If you want to allow users to easily link in the sanitizer runtime even if they specify `-nodefaultlibs`, I think the user should explicitly opt into that via another driver flag (e.g., `clang -nodefaultlibs -fsanitize=address -flink-sanitizer-runtime=address`). Then the command line is explicit about the intent, and each flag has the obvious meaning. https://reviews.llvm.org/D24048 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
