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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
  • [PATCH] D42092: i... Richard Smith - zygoloid via Phabricator via cfe-commits
    • [PATCH] D420... John McCall via Phabricator via cfe-commits
    • [PATCH] D420... Richard Smith - zygoloid via Phabricator via cfe-commits
    • [PATCH] D420... John McCall via Phabricator via cfe-commits

Reply via email to