ojhunt wrote: > I think we should make a point of implementing this for address-discriminated > `__ptrauth` qualifiers before we release it, because changing the type trait > in a future release will be an ABI break.
I had been talking to @cor3ntin and decided we could do it later as this is all intrinsics and semantics that would be tied to a single TU, but I can see that it would result in different symbols being resolved or produced. We felt that it would be sufficiently localized to TU level behavior that it wouldn't leak, but I could see that I might be possible to get it leak out from there. @rjmccall Do you have an example you're thinking of that you think is plausible - just so I can't mull it/turn it over in my head? The earlier implementation did fixup address discriminated explicitly qualified data, and as you commented (not on GH) you can see the model I built out for the fixups easily supports that so it's not an implementation difficulty problem (there are some performance questions that come up, but they're just QoI issues that can be addressed without changing behavior or semantics). https://github.com/llvm/llvm-project/pull/144420 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
