rsmith added a comment. In https://reviews.llvm.org/D24048#537257, @beanz wrote:
> @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. Your claim about the existing `-fsanitize` options seems off the mark -- at least `-fsanitize=` and `fsanitize-link-c++-runtime` already affect the driver linking behaviour, not just the compiler-inserted runtime checks. And more generally, we're trying to group our driver options based on prefixes, so `-flink-sanitizer-runtimes` is not appropriate on that basis. > 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. I think it depends a lot on how you set up your build system. If you have one set of flags for compilation steps and one set of flags for link steps, then adding `-fsanitize=` to the link flags is pretty clearly requesting that you link against the sanitizer runtimes. This is, in fact, the documented meaning of passing `-fsanitize=` when linking (http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation). If, on the other hand, you have a common set of flags passed to both compilations and links, then perhaps you could argue that you're not explicitly opting in. However, as there are a large number of Clang compilation flags (`-f` flags in particular) that will cause the link to fail if they're passed to the driver when linking, someone will have needed to choose to add the flags to the "both compile and link" flag set to get into this state (rather than adding them just to the "compile" flag set, which should be the default choice), and again this seems like an explicit statement of intent. I don't see the point of adding another flag to control this when we already have a perfectly good set of flags that already do the right thing -- that takes us three levels deep in flags overriding the behavior of other flags, and I don't see how it actually helps our users in any way. https://reviews.llvm.org/D24048 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
