srhines added a comment. In D77168#1988122 <https://reviews.llvm.org/D77168#1988122>, @jfb wrote:
> In D77168#1988049 <https://reviews.llvm.org/D77168#1988049>, @srhines wrote: > > > `pragma clang attribute` is interesting, but how do you apply that in a > > selective fashion to local variables (especially in a way that can be > > automated)? At first, I didn't think the goal for this should be to create > > a frequently used option for **most** end users, but I do think that it > > could be quite useful for more folks when debugging, especially if it is > > easy to automate (which optimization-fuel approaches are, while pragmas are > > not). > > > `__attribute__((uninitialized))` for more selectiveness :) > > Of course, not automated. In general we don't really automate compiler things > of this sort, say UBSan. OptRemarks is the best we really have to dig into > these things. One other option would be to truly randomize the init pattern: > emit a handful of different byte patterns, and then see the crash caused by a > different pattern, and track it back to which local variable got that byte > pattern. That's just it though. This technique is tried and true in other compilers/tools. Why should we let past history dictate whether to facilitate automation in the present/future? Rather than having to "track it back", you can let the tooling do it for you. It gets you at least a breakage related to this transformation, and the best part is you can fix that one, and then run it again to chase down further issues. All without modifying source code. I feel like I can't be the only one who has used these kinds of tools for debugging transformations before, hence why I feel so invested in making this easy for everyone (compiler devs and regular users). UBSan isn't as relevant as it can provide diagnostics for the particular instance in which it was tripped. If we wanted to do something similar for initialization, we would have to mark the uninitialized value and track down any potential use of it, which seems like a lot more complexity and decreased performance too. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77168/new/ https://reviews.llvm.org/D77168 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
