nhaehnle added a comment. In D130224#3668225 <https://reviews.llvm.org/D130224#3668225>, @aaron.ballman wrote:
> I'm in C standards meetings this week and don't have a lot of ability to > thoroughly review this yet, but the most immediate concern which springs to > mind for me is that this is exposing LLVM implementation details to users. > Users should not have to think about things in terms of LLVM IR markings like > poison and undef, and I worry that this is an expert-only feature that will > be easy to misuse and introduce security issues. Here's how I would tentatively describe the attribute in terms that mesh better with how I understand C and C++: > As an exception to the rule that loading from an unitialized variable is > undefined behavior, if the loaded value is used immediately as an > `__attribute__((maybe_undef))` argument in a function call, the loaded value > is implementation-defined. It may vary between multiple runs of the program, > and it may vary between multiple uses of the uninitialized variable. This requires no thinking about LLVM IR and undef/poison. There may have to be some caveats about bools and enums (generally, types where not all possible values in memory are actually legal values of the type), but I don't know enough about those language standards to judge that. ================ Comment at: clang/include/clang/Basic/AttrDocs.td:276 + + void maybeundeffunc(void __attribute__((maybe_undef))param); + }]; ---------------- `param` shouldn't be of void type, right? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130224/new/ https://reviews.llvm.org/D130224 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
