Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
Instead of ignoring the evaluation order rule, ignore the "destroy parameters in reverse construction order" rule for the small number of problematic cases. This only causes incorrect behavior in the rare case where both parameters to an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with non-trivial destructor, and the program is depending on those parameters being destroyed in reverse construction order. We could do a little better here by reversing the order of parameter destruction for those functions (and reversing the argument evaluation order for all direct calls, not just those with operator syntax), but that is not a complete solution to the problem, as the same situation can be reached by an indirect function call. Approach reviewed off-line by rnk. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282777 91177308-0d34-0410-b5e6-96231b3b80d8
Showing
- lib/CodeGen/CGCall.cpp 26 additions, 25 deletionslib/CodeGen/CGCall.cpp
- lib/CodeGen/CGExpr.cpp 25 additions, 7 deletionslib/CodeGen/CGExpr.cpp
- lib/CodeGen/CGExprCXX.cpp 1 addition, 1 deletionlib/CodeGen/CGExprCXX.cpp
- lib/CodeGen/CodeGenFunction.h 12 additions, 4 deletionslib/CodeGen/CodeGenFunction.h
- test/CodeGenCXX/cxx1z-eval-order.cpp 22 additions, 33 deletionstest/CodeGenCXX/cxx1z-eval-order.cpp
- www/cxx_status.html 4 additions, 6 deletionswww/cxx_status.html
Loading
Please register or sign in to comment