rsmith added a comment. I'm concerned about the complexity of this approach; it's hard for me to be confident that `BuildScopeInformation` is correct and will remain correct in the presence of future changes to the AST, and if it's not, we'll potentially silently miscompile.
A simpler but less precise approach would be to disable lifetime markers for all variables for which it is possible to jump into their scope (that is, in C++, variables of suitably-trivial types with no explicit initializer, and in C, variables of non-variably-modified type) whose scopes contain any kind of label. I'd have a lot more confidence that such an approach would be -- and would remain -- correct. I'd also like to see some tests for `indirectbr`s (computed goto) since they're the case where we would have the most trouble producing the correct set of lifetime markers. On the other hand, for ASan's purposes, we really want a precise set of markers here. If we can determine the set of variables brought into scope by each goto/computed goto/switch branch that we emit, we can split the edge or (for an unsplittable edge) insert a conditional branch into the destination block to call the lifetime start intrinsic. This would require CodeGen to track the set of live variables and store it for each such branch and branch target so that we can refer to it when fixing up the relevant edge, but that doesn't seem prohibitively expensive, and it would avoid any cost in the common case of a function containing no branches and no branch targets. https://reviews.llvm.org/D24693 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
