aaron.ballman added a comment.
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>();
}
================
Comment at: clang/include/clang/Basic/AttrDocs.td:5789
+command-line parameter, forcing variables to remain uninitialized.
+When set on a struct or class, all stack variables of this type are affected.
+
----------------
================
Comment at: clang/lib/CodeGen/CGDecl.cpp:1908
- // Note: constexpr already initializes everything correctly.
- LangOptions::TrivialAutoVarInitKind trivialAutoVarInit =
- (D.isConstexpr()
- ? LangOptions::TrivialAutoVarInitKind::Uninitialized
- : (D.getAttr<UninitializedAttr>()
- ? LangOptions::TrivialAutoVarInitKind::Uninitialized
- : getContext().getLangOpts().getTrivialAutoVarInit()));
+ LangOptions::TrivialAutoVarInitKind trivialAutoVarInit;
+ if (D.isConstexpr()) {
----------------
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D156337/new/
https://reviews.llvm.org/D156337
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
