GkvJwa 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.
Yes, skipping it using the first instruction is indeed incorrect.(BB.isEHPad()) https://github.com/llvm/llvm-project/blob/0952ccc712ffc97943fbd0fc3c38a53e7aa875ac/llvm/lib/CodeGen/WinEHPrepare.cpp#L592-L608 I will try to make it, can also comment if anyone has an idea https://github.com/llvm/llvm-project/pull/172287 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
