[all-commits] [llvm/llvm-project] e32f8e: [Windows EH] Fix the order of Nested try-catches i...

[tentzen via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: e32f8e5d4ae88c2934f310f3f8a762f969bc6793
      https://github.com/llvm/llvm-project/commit/e32f8e5d4ae88c2934f310f3f8a762f969bc6793
  Author: Ten Tzen <tentzen at microsoft.com>
  Date:   2020-05-15 (Fri, 15 May 2020)

  Changed paths:
    M llvm/lib/CodeGen/WinEHPrepare.cpp
    A llvm/test/CodeGen/AArch64/win-catchpad-nested-cxx.ll
    M llvm/test/CodeGen/X86/win-catchpad-nested-cxx.ll

  Log Message:
  -----------
  [Windows EH] Fix the order of Nested try-catches in $tryMap$ table

This bug is exposed by Test7 of ehthrow.cxx in MSVC EH suite where
a rethrow occurs in a try-catch inside a catch (i.e., a nested Catch
handlers). See the test code in
https://github.com/microsoft/compiler-tests/blob/master/eh/ehthrow.cxx#L346

When an object is rethrown in a Catch handler, the copy-ctor of this
object must be executed after the destructions of live objects, but
BEFORE the dtors of live objects in parent handlers.

Today Windows 64-bit runtime (__CxxFrameHandler3 & 4) expects nested Catch
handers
are stored in pre-order (outer first, inner next) in $tryMap$ table, so
that given a State, its Catch's beginning State can be properly
retrieved. The Catch beginning state (which is also the ending State) is
the State where rethrown object's copy-ctor must take place.

LLVM currently stores nested catch handlers in post-ordering because
it's the natural way to compute the highest State in Catch.
The fix is to simply store TryCatch handler in pre-order, but update
Catch's highest State after child Catches are all processed.

Differential Revision: https://reviews.llvm.org/D79474?id=263919