rjmccall wrote: Okay, it sounds like this is where we've left off: - The standard is using an odd formulation in [[class.cdtor]p2](https://eel.is/c++draft/class.cdtor) that we're not sure how to interpret. It's possible that it's formally slightly weaker than `restrict` might be, which would make `noalias` technically incorrect, but we aren't sure if there are actually any LLVM optimizations that would do anything that this wouldn't allow. If we had an attribute that captured these slightly weaker semantics, we're confident that this would be okay, but it might be fine to just use `noalias`. - We're worried about enabling new UB-based optimizations by default, especially ones that we can't reliably diagnose dynamically with sanitizers.
Is that an accurate summary? https://github.com/llvm/llvm-project/pull/136792 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
