MuellerMP wrote: > I think this flew under the radar when this was all getting implemented > because we didn't handle async exceptions, so designed the problem away by > just turning off EH cleanups if SEH try was used in a function body. I > suppose -EHa undoes that logic, bringing this problem back to life. > > Personally, I don't like the design proposed here of adding a standalone > recursive walk of the AST and attempting to pattern match things that might > not compile. If the asynch EH numbering algorithm has bugs, I think we'd be > better off improving the backend diagnostic to try to make it more actionable > to users with LLVM IR debug info. We can leverage the internal / user fatal > error distinction and some source locations to emit a more readable error > diagnostic and that will help in all cases, instead of having this pattern > match that creates additional maintenance and that we can't guarantee fixes > all holes in the asynch EH numbering scheme.
This reads similar to what i tried to suggest here: https://github.com/llvm/llvm-project/pull/172287#discussion_r2634654818 In this case we just handle the case for emitting a `seh.scope.begin`, which is exactly what we do not handle in the SEH state numbering (only in the CXX state numbering). https://github.com/llvm/llvm-project/pull/172287 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
