C++ 为什么GCC复制这个对象而不调用move或copy构造函数？

我正在将一个可移动对象传递给lambda-expression-cast-to-a-function-pointer，似乎程序沿着这条线的某个地方创建了对象的逐位拷贝，而没有调用copy或move构造函数。这会导致资源被双重释放，因为对象的“真实”副本不知道它已移出

更详细的跟踪在MCVE代码之后

MCVE：

输出：

0x7fff57dcbe20 default-constructing   <-- t.arg
0x7fff57dcbe38 default-constructing   <-- t.result
0x7fff57dcbdc0 move-constructing with 1 values from 0x7fff57dcbe20
                                      ^-- argument to lambdaFunc
0x7fff57dcbd70 used in lambda         <-- HUH!? That's not the address of an object that was constructed!
                                      It seems to be a bitwise copy of 0x7fff57dcbdc0
0x7fff57dcbde0 move-constructing with 1 values from 0x7fff57dcbd70
                                      <-- return value; when we move out of ...70, this doesn't affect the real object ...c0
0x7fff57dcbe38 move-assigning         1 values from 0x7fff57dcbde0
                                      ^-- assigning to t.result
0x7fff57dcbde0 destructing with       0 values:
0x7fff57dcbdc0 destructing with       1 values:
 TheValue
                                      ^-- Uh oh, because of all the move assignments, ...c0 and ...38 are pointing to the same memory, which is now free
0x7fff57dcbe38 destructing with       1 values
Segmentation fault      (core dumped) <-- trying to print a string that is now freed

---

这个程序有什么问题吗？

我可以用它玩吗。由于gcc 6.1，它在两种情况下都有效。对于Clang3.2，它会生成非法指令（？）。顺便说一句：我也查看了汇编代码，以确认GCC生成了按位拷贝，而不是传递垃圾指针。那么，听起来好像已经解决了codegen问题。

$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

0x7fff57dcbe20 default-constructing   <-- t.arg
0x7fff57dcbe38 default-constructing   <-- t.result
0x7fff57dcbdc0 move-constructing with 1 values from 0x7fff57dcbe20
                                      ^-- argument to lambdaFunc
0x7fff57dcbd70 used in lambda         <-- HUH!? That's not the address of an object that was constructed!
                                      It seems to be a bitwise copy of 0x7fff57dcbdc0
0x7fff57dcbde0 move-constructing with 1 values from 0x7fff57dcbd70
                                      <-- return value; when we move out of ...70, this doesn't affect the real object ...c0
0x7fff57dcbe38 move-assigning         1 values from 0x7fff57dcbde0
                                      ^-- assigning to t.result
0x7fff57dcbde0 destructing with       0 values:
0x7fff57dcbdc0 destructing with       1 values:
 TheValue
                                      ^-- Uh oh, because of all the move assignments, ...c0 and ...38 are pointing to the same memory, which is now free
0x7fff57dcbe38 destructing with       1 values
Segmentation fault      (core dumped) <-- trying to print a string that is now freed

0x7ffe3b11b910 default-constructing   <-- t.arg
0x7ffe3b11b928 default-constructing   <-- t.result
0x7ffe3b11b8b0 move-constructing with 1 values from 0x7ffe3b11b910
0x7ffe3b11b8b0 used in global function<-- The same object that was just constructed
0x7ffe3b11b8d0 move-constructing with 1 values from 0x7ffe3b11b8b0
0x7ffe3b11b928 move-assigning         1 values from 0x7ffe3b11b8d0
0x7ffe3b11b8d0 destructing with       0 values:
                                      ^-- The values are not freed because this object was emptied when it was moved from.
0x7ffe3b11b8b0 destructing with       0 values:
0x7ffe3b11b928 destructing with       1 values:
 TheValue
0x7ffe3b11b910 destructing with       0 values: