[Bug c++/110394] Lambda capture receives wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394 --- Comment #7 from Andrew Pinski --- (In reply to jackyguo18 from comment #6) > @Andrew Pinski - Thanks, just confirmed that that was the issue. > > Why doesn't GCC choose to delete the function (thus causing the weird > behaviour) early at lower optimization levels? > > Seems kinda strange it would work at -O2. Most likely inlining more and being more agressive of doing some optimizations. Since it is undefined behavior if you use the object after the lifetime ends, it is just happened to work at different levels of optimization really.
[Bug c++/110394] Lambda capture receives wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394 jackyguo18 at hotmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from jackyguo18 at hotmail dot com --- @Andrew Pinski - Thanks, just confirmed that that was the issue. Why doesn't GCC choose to delete the function (thus causing the weird behaviour) early at lower optimization levels? Seems kinda strange it would work at -O2.
[Bug c++/110394] Lambda capture receives wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394 --- Comment #5 from jackyguo18 at hotmail dot com --- @Andrew Pinski - Thanks, just confirmed that that was the issue. Why doesn't GCC choose to delete the function (thus causing the weird behaviour) early at lower optimization levels? Seems kinda strange it would work at -O2.
[Bug c++/110394] Lambda capture receives wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #4 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #3) > You can also try -fno-lifetime-dse to see if you get the behavior you were > expecting too. Though I am not sure it will help extend the lifetime of the > temporary here ... > > > https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html#index- > flifetime-dse -fstack-reuse=named_vars maybe needed as well. -flifetime-dse preserves the stores outside of the lifetime, and -fstack-reuse=named_vars disallows reusing the stack space of the temporary object for other objects.
[Bug c++/110394] Lambda capture receives wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394 --- Comment #3 from Andrew Pinski --- You can also try -fno-lifetime-dse to see if you get the behavior you were expecting too. Though I am not sure it will help extend the lifetime of the temporary here ... https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html#index-flifetime-dse
[Bug c++/110394] Lambda capture receives wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2023-06-24
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
I am almost think this is a bug in your code.
Take:
auto wait_handle = tc::g_postbox->wait(
"UpdateInputs"sv, [=](const msgpack::object& obj) -> bool {
});
The temporary for tc::postbox::acceptor_type will end its lifetime at the end
of that statement but tc::g_postbox->wait stores it off into m_awaiters.
And then gets poped off with:
wait_handle.await();
You can fix this via extending the temporary via:
```
tc::postbox::acceptor_type t = [=](const msgpack::object& obj) -> bool {
auto [rcv_index, rcv_value] = obj.as>();
tc::tracef(M64MSG_VERBOSE, "index = {}", index);
if (rcv_index != index)
return false;
keys->Value = rcv_value;
return true;
};
auto wait_handle = tc::g_postbox->wait(
"UpdateInputs"sv, t);
```
Note `-fsantize=address` should catch this at runtime too.
[Bug c++/110394] Lambda capture receives wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394 --- Comment #1 from jackyguo18 at hotmail dot com --- Created attachment 55396 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55396=edit .ii file which triggers the bug I couldn't attach the original .ii file, so I had to compress it under gzip.
