hfinkel added a comment. In https://reviews.llvm.org/D32199#731472, @rsmith wrote:
> > As I've currently implemented it, both reads and writes set the type of > > previously-unknown storage, and after that it says fixed (unless you memcpy > > to it, memset it, or its lifetime ends (the type gets reset on > > lifetime.start/end and for malloc/allocas/etc.). There's a flag to enable > > the "writes always set the type" rule, but that's not the default. Is this > > too strict? > > That seems like it will have at least three flavors of false positive: > > 1. C's "effective type" rule allows writes to set the type pretty much > unconditionally, unless the storage is for a variable with a declared type > 2. After a placement new in C++, you should be able to use the storage as a > new type > 3. Storing directly to a member access on a union (ie, with the syntax `x.a = > b`) in C++ permits using the storage as the new type > > If we want to follow the relevant language rules by default, that would > suggest that "writes always set the type" should be enabled by default in C > and disabled by default in C++. That may not be the right decision for other > reasons, though. In C++, writes through union members and new-expressions > should probably (re)set the type Fair enough. For now we'll default to write-sets-the-type as the default. We can always add 'sticky' types later to correspond to types set by declaration. > (do you have intrinsics the frontend can use to do so?). I had thought that we could just use a lifetime.end/start pair to mark the placement new, etc. However, it might be better to use some dedicated intrinsic for this purpose? https://reviews.llvm.org/D32199 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
