This attribute would then affect all stack variables of that type, when the type has been evaluated as ok wrt. initialisation, or a for performance / security trade-offs.
An example of use could be container with preallocated storage like SmallVector, if we consider that it is too costly to initialize that storage.
Details
- Reviewers
jfb aaron.ballman - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I think a test verifying that during constant evaluation we still flag the read of a local tagged uninitialized as ill-formed would be nice.
Was there an RFC for this extension to the attribute? (There doesn't need to be one, I'm just wondering if there's more background info on what's driving this patch forward and discussion around the design.)
I'd like some more details about how this attribute impacts class hierarchies. e.g., if you put the attribute on the base class, does it impact the derived class members as well, or just the base class members? Also, what should happen in a case like this:
template <typename Ty> void func() { Ty Val; // Does this know it's uninitialized? Or did we lose that information because this isn't a type attribute? } struct __attribute__((uninitialized)) S { int value; }; int main() { func<S>(); }
clang/include/clang/Basic/AttrDocs.td | ||
---|---|---|
5786 | ||
clang/lib/CodeGen/CGDecl.cpp | ||
1905–1915 |
All very relevant topics. Concerning inheritance, I'd say that if the base class is marked as uninitialized and the child class is not, then base members are uninitialized and child members are not.
Concerning your example, I'd expect Val to be uninitialized as it's type has the according attribute, but I also don't quite understand "Or did we lose that information because this isn't a type attribute?"