GkvJwa wrote: > My general take on this issue: since msvc rejects this it would not be > unreasonable to reject this in clang aswell for compatibility reasons and to > avoid overall complexity in the state handling. > > Regarding this patch: The C++ state numbering condition aswell as the Filter > state numbering fix are not required for this issue and are not covered by > tests. As far as I can tell the only fix covered by the test is the SEH state > numbering `State > 0` condition for the `seh_try_end` invoke right? > > Now what actually causes the issue: We choose the `calculateSEHStateNumbers` > function instead of the `calculateWinCXXEHStateNumbers` Function in > FunctionLoweringInfo due to this function having the `__C_specific_handler` > personality. The `calculateSEHStateNumbers` function currently does **NOT** > know about C++ EH constructs like the emitted `seh_scope_begin`. We simply > skip over it in the state numbering which causes the issue. We could "fix" > this by either supporting `seh_scope_begin` in `calculateSEHStateNumbers` or > choosing the C++ unwinder in the frontend (latter one would be preferable and > more sound IMO). > > =>But like I said: I would rather choose to reject this in the frontend.
I checked the compiled code, and it didn't reject anything. The front-end can generate `ll` files; the problem only arises when generating `obj` files. https://github.com/llvm/llvm-project/pull/172287 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
