[PATCH] D42092: implement C++ dr388 for the Itanium C++ ABI: proper handling of catching exceptions by reference

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D42092#1057881, @rsmith wrote:

> In https://reviews.llvm.org/D42092#983892, @rjmccall wrote:
>
> > This is definitely something that the personality function should handle.  If we want to do heroic things in the absence of personality function support, we can, but the code should at least be written to be conditional on personality support.
>
>
> I suppose the question is, do we want to do such heroic things?
>
> Also, we don't have a personality function that can get this right, nor even a concrete design proposed for one. It doesn't seem too hard -- we'd need to extend the EH table to indicate catch-by-reference -- but there's nothing for this to be made conditional on right now. I can easily add a CodeGenOption that turns this all off, if you'd like.


Well, I don't have a use case for an option like that.  If we're going to add the code to support this even without a cooperative personality, I think we can enable it unconditionally for now.

Issue #3 is tricky; it's arguably not okay to force a landing at a landing pad if we're not actually catching anything.

For what it's worth, I don't think the Itanium ABI needs any changes here.  The existence of any particular personality function, and that function's expectations about the LSDA, are not official ABI.   __gxx_personality_v0 is a sort of private ABI, a standard solution offered by libsupc++ / libc++abi for the convenience of compilers, but we could totally just write a new personality and add it to compiler-rt (or libc++abi, enabled by deployment-target-specific checks) if that was the best solution.

>> If we can rev the personality function, we should also fix the longstanding problem with references to pointers to classes.
> 
> Which issue is that? (And does this patch fail to address it? It should prevent catching `Derived*` by (non-const) `Base *&` while still allowing catch by `Base *const&`, if that's the issue you're referring to.)

Yes, that's the issue I'm referring to, and yeah, I see that you're addressing it here.


Repository:
  rC Clang

https://reviews.llvm.org/D42092