Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
authorRichard Smith <richard-llvm@metafoo.co.uk>
Thu, 29 Sep 2016 21:30:12 +0000 (21:30 +0000)
committerRichard Smith <richard-llvm@metafoo.co.uk>
Thu, 29 Sep 2016 21:30:12 +0000 (21:30 +0000)
commitc15b46ecb60f8a490cefac945e6cff5280f25cac
tree28591b65104c3e2abef78fc96b66f564f026cded
parentce09b185b48ab28a787951c1047980fb0d543f3a
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
lib/CodeGen/CGCall.cpp
lib/CodeGen/CGExpr.cpp
lib/CodeGen/CGExprCXX.cpp
lib/CodeGen/CodeGenFunction.h
test/CodeGenCXX/cxx1z-eval-order.cpp
www/cxx_status.html