hfinkel added a comment. In https://reviews.llvm.org/D32199#731249, @hfinkel wrote:
> In https://reviews.llvm.org/D32199#731144, @rsmith wrote: > > > > > > ... > > > I would also expect that we will extend this in future to assign types to > > storage even in cases where there is no store (for instance, we should be > > able to catch `float f() { int n; return *(float*)&n; }` despite there > > being no TBAA violation in the naive IR). > > Yes. My thought was that we'd make Clang generate tbaa metadata on allocas > and lifetime.start intrinsics (and globals) so that we can mark the memory > types upon creation. Would that catch everything? Also, we'd also want to do something similar for byval arguments. This may just be additional motivation to allow metadata on function arguments (there's an RFC on llvm-dev about this presently). > > >> How about renaming this to something more like `-fsanitize=type`? > > I'm fine with that. Do you like TypeSanitizer or TypeAccessSantizer or > TypeAliasingSanitizer best? > > One potential concern with calling it the type sanitizer is that we have an > abbreviation overlap with the thread sanitizer. https://reviews.llvm.org/D32199 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
