dblaikie added a comment. In D90719#2387379 <https://reviews.llvm.org/D90719#2387379>, @akhuang wrote:
> + @ldionne for libc++ input? > > To summarize, this constructor homing debug info optimization makes the > assumption that if a class is being used then its constructor must have been > called at some point. We noticed that some libc++ types (such as __hash_node) > are nontrivial but the constructor is never called (instead there's some > allocation and then the members are constructed separately). > > Basically we're not sure if this can be fixed from the libc++ side but it > would be nice to have some more input about this. For example would it be > possible to call the constructor when __hash_node is created? > >> My guess would be that this doesn't come up often enough to merit an >> attribute, etc, and that libc++ is fixable. (if the code really wants to do >> no work when constructing, changing the type to have a trivial ctor and the >> places that want non-trivial construction can initialize the members as >> needed seems like it'd be viable) > > I looked at the code again and `__hash_node` also has nontrivial members, so > maybe it's not as feasible to make it a nontrivial constructor. At least my thinking is: If this type is being constructed without executing a constructor and the code is correct (modulo UB, but correct for the behavior it happens to be getting) then it doesn't really need those ctors to run - so perhpas they shouldn't be there either/should be trivial, because they're not being used, at least here. That's my theory, at least. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90719/new/ https://reviews.llvm.org/D90719 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
