[PATCH] D79760: [WinEH64] Fix a crush issue when c++ exception nested in a particular form.

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added a comment.

I don't understand why this difference exists. Beyond just trying to reproduce what MSVC does, can you explain the difference?



================
Comment at: llvm/lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp:106
     WinEHFuncInfo &EHInfo = *MF->getWinEHFuncInfo();
+    Triple::ArchType Arch = MF->getSubtarget().getTargetTriple().getArch();
     if (Personality == EHPersonality::MSVC_CXX)
----------------
It's probably better to use Triple::isArch64Bit here. I think your patch will break non-x86 Windows.


================
Comment at: llvm/test/CodeGen/X86/win-catchpad-nested-cxx.ll:65
 
-; CHECK: $tryMap$try_in_catch:
-; CHECK-NEXT: .long   2
-; CHECK-NEXT: .long   2
-; CHECK-NEXT: .long   3
-; CHECK-NEXT: .long   1
-; CHECK-NEXT: .long   ($handlerMap$0$try_in_catch)
-; CHECK-NEXT: .long   0
-; CHECK-NEXT: .long   0
-; CHECK-NEXT: .long   3
-; CHECK-NEXT: .long   1
-; CHECK-NEXT: .long   ($handlerMap$1$try_in_catch)
+; X86-LABEL: $tryMap$try_in_catch:
+; X86-NEXT: .long   2
----------------
This case is different than the case you are fixing, right? Can you add a test for the case in the bug report?

Also, it seems the x64 case here produces the same try-map entries but with the order of the map entries reversed. Is that correct? We're probably doing too much wild card matching in the handler map, because we really need to make sure the combination of try-map entries and handler-map entries leads to the correct handler.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79760/new/

https://reviews.llvm.org/D79760