rjmccall added a comment. In D74361#1896982 <https://reviews.llvm.org/D74361#1896982>, @JonChesterfield wrote:
> In D74361#1879559 <https://reviews.llvm.org/D74361#1879559>, @rjmccall wrote: > > > This will need to impact static analysis and the AST, I think. Local > > variables can't be redeclared, but global variables can, so disallowing > > initializers syntactically when the attribute is present doesn't > > necessarily stop other declarations from defining the variable. Also, you > > need to make the attribute mark something as a definition, the same way > > that e.g. the alias attribute does. Also, this probably ought to disable > > the default-initialization of non-trivial types in C++, in case that's not > > already done. > > > I would like this to be the case but am having a tough time understanding how > sema works. VarDecl::hasInit() looked promising but doesn't appear to > indicate whether there is a syntactic initialiser (e.g. = 10) present. I will > continue to investigate. Codegen appears to be working fine. Looks like you figured this out. > In D74361#1880904 <https://reviews.llvm.org/D74361#1880904>, @jfb wrote: > >> The current uninitialized attribute fits the model C and C++ follow for >> attributes: they have no semantic meaning for a valid program, in that a >> compiler can just ignore them and (barring undefined behavior) there's no >> observable effect to the program. This updated semantic changes the behavior >> of a valid C and C++ program, because the standards specify the value of >> uninitialized globals and TLS. I'd much rather have a separate attribute, >> say `no_zero_init`, to explicitly say what this does. > > > This proposed attribute can similarly be ignored without observable semantic > effect. Instead of an IR undef variable, we would have an IR zeroinitialized > variable, which is a legitimate implementation choice for undef. Adding the > attribute to an existing program will, in general, change its meaning - but > that's also true of other attributes. I agree with this reasoning, but since you seem willing to change the attribute name, the point is now moot. ================ Comment at: clang/include/clang/Basic/Attr.td:3436 + let Subjects = SubjectList<[GlobalVar]>; + let Documentation = [Undocumented]; +} ---------------- We try to always add documentation for any new attribute. I'm not sure I like the new name; it doesn't read right to me. Maybe `loader_uninitialized` makes the intent clear enough? Thinking more about it, I agree with you that this is orthogonal to C++ initialization. Users on targets like yours probably ought to be able to disable C++ initialization without having to disable zero-initialization, or vice-versa. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74361/new/ https://reviews.llvm.org/D74361 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
