GkvJwa wrote:
@MuellerMP hello, I'm sorry to bother you again
We mentioned this sample earlier.
```
struct A {
~A();
};
void f() {
__try {
A* a = new A;
delete a;
} __finally {
}
}
```
At the time, I analyzed that it was caused by the insertion of an extra
`llvm.seh.try.end()/invoke.cont7` instruction.
```
....
invoke.cont7: ; preds = %invoke.cont6
invoke void @llvm.seh.try.end()
to label %invoke.cont8 unwind label %ehcleanup10
.....
delete.end: ; preds = %invoke.cont9,
%invoke.cont3
invoke void @llvm.seh.try.end()
to label %invoke.cont13 unwind label %ehcleanup14
...
```
Upon further analysis, I realized that the problem stemmed from inserting too
many SEH calls within the same function context in the current framework.At the
same time, the code generated by MSVC does not generate as many `__try` blocks
as LLVM.
Then, I removed the `EmitSehTryScopeEnd` instruction from that location. At
this point, LLVM is no longer crashing, and the generated code is also correct.
Therefore, the problem here might be that in the same block, multiple
emits(`Emit*ScopeEnd`/`Emit*ScopeBegin`) are not needed on Windows when use
'/eha'. The system mechanism shouldn't require multiple nested calls within the
same stack(the same function)
I think this is somewhat related to this PR(#167176). So I'd like to ask for
your opinion. We may need to ensure that we don't nest multiple handlers when
`SEH` is enabled.
CC @rnk @efriedma-quic
https://github.com/llvm/llvm-project/pull/180144
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
