ilya-biryukov wrote: I second @cor3ntin's concern here. We are adding a builtin that is named very similarly to the one from C++23 standard, but not actually having the semantics that is desired.
I believe we do need the effect that __builtin_launder provides to allow memcpy for types that have vtables, which was original motivation for this change and #86512. However, we could get those guarantees by using __builtin_launder directly. Looking at the code, the __builtin_launder currently has a sole effect of preventing optimizations that would load an incorrect vtable when -fstrict-vtable-pointers is passed and same storage is reused for different types. I feel it's better to just go with std::launder on our end at this point and instead focus on preventing misoptimizations from TBAA to get a proper implementation of start_lifetime_as. It carries a risk of hitting a misoptimization in the future on our end, but seems very unlikely unless we start using TBAA or LLVM starts optimizing much more aggressively based on C++ notion of object lifetimes, neither of which should go unnoticed. @hokein WDYT? https://github.com/llvm/llvm-project/pull/82776 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
