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

Reply via email to