aaron.ballman added a comment. In https://reviews.llvm.org/D26454#609578, @dougk wrote:
> Suppression of sanitizing is necessary if the variable is magically a > memory-mapped device I/O address. > The linker can arrange for this to be the case using fancy scripts, or even > just as simple as a section attribute that requires that you take up exactly > a certain number of bytes in the section. > There was some thought that any non-default section should preclude > sanitization, but Kostya said that, no, it would make sense to require > explicit no-sanitize. I (mistakenly) took that to mean "just do it", for > which I apologize. Thank you for the explanation, but I'm still wondering if this applies to only `address` sanitization, or to others as well, such as `memory` or `thread`. The fact that the declarative information in Attr.td is incorrect now is a concern. We can either address that concern by making the conflict go away for all sanitizer strings (which may not be sensible), or by making some complex changes to the way subject lists work (which may be more work than it's worth). The point to having a single `no_sanitize` attribute was so that we didn't need to add a new attribute every time we came up with a new sanitizer, but it was understood that this works because all of the sanitizers apply to the same constructs. This change breaks that assumption so that now one of the sanitizer strings diverges from all the rest, and I would like to avoid that. https://reviews.llvm.org/D26454 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
