GkvJwa wrote:
> @GkvJwa My point is that the `ll` could already be considered ill formed - as
> explained in `Now what actually causes the issue`. But I agree that not only
> the clang frontend but also LLC should reject this IMO. Besides that your
> test does actually include the clang frontend here.
Okay, so if we find a class object in llvm.eh.exceptionCode, is it feasible to
directly refuse compilation?
```
catch.dispatch: ; preds = %invoke.cont, %entry
%2 = catchswitch within none [label %__except] unwind to caller
__except: ; preds = %catch.dispatch
%3 = catchpad within %2 [ptr null]
catchret from %3 to label %__except2
__except2: ; preds = %__except
%4 = call i32 @llvm.eh.exceptioncode(token %3)
store i32 %4, ptr %__exception_code, align 4
call void @"?bb@aa@@SA?AV1@XZ"(ptr dead_on_unwind writable sret(%class.aa)
align 1 %agg.tmp.ensured)
invoke void @llvm.seh.scope.begin()
to label %invoke.cont3 unwind label %ehcleanup
invoke.cont3: ; preds = %__except2
invoke void @llvm.seh.try.end()
to label %invoke.cont4 unwind label %ehcleanup
invoke.cont4: ; preds = %invoke.cont3
call void @"??1aa@@QEAA@XZ"(ptr noundef nonnull align 1 dereferenceable(1)
%agg.tmp.ensured) #5
br label %__try.cont
__try.cont: ; preds = %invoke.cont4,
%invoke.cont1
ret void
invoke.cont1: ; preds = %invoke.cont
br label %__try.cont
ehcleanup: ; preds = %invoke.cont3,
%__except2
%5 = cleanuppad within none []
call void @"??1aa@@QEAA@XZ"(ptr noundef nonnull align 1 dereferenceable(1)
%agg.tmp.ensured) #5 [ "funclet"(token %5) ]
cleanupret from %5 unwind to caller
}
__except2: ; preds = %__except
%4 = call i32 @llvm.eh.exceptioncode(token %3)
store i32 %4, ptr %__exception_code, align 4
call void @"?bb@aa@@SA?AV1@XZ"(ptr dead_on_unwind writable sret(%class.aa)
align 1 %agg.tmp.ensured)
invoke void @llvm.seh.scope.begin()
// has callinst
```
https://github.com/llvm/llvm-project/pull/172287
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
