[Bug other/110394] New: Lambda capture receives wrong value

[Bug other/110394] New: Lambda capture receives wrong value

[jackyguo18 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

            Bug ID: 110394
           Summary: Lambda capture receives wrong value
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jackyguo18 at hotmail dot com
  Target Milestone: ---

Note that this doesn't occur in Clang, and to my knowledge, disabling strict
aliasing and overflow would make no difference.

The code submitted here is actually part of a larger library. When I go to
debug it, a lambda in `GetKeys(int index, BUTTONS* keys)` captures the wrong
value for `index`--it should be 0, but it's 23.

Changing the capture type from value to reference causes the lambda to
inexplicably call the address 0x17 (decimal 23).

[Bug c++/110394] Lambda capture receives wrong value

[jackyguo18 at hotmail dot com]

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&action=edit
.ii file which triggers the bug

I couldn't attach the original .ii file, so I had to compress it under gzip.

[Bug c++/110394] Lambda capture receives wrong value

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-06-24
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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<std::tuple<int, uint32_t>>();
    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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(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

[jackyguo18 at hotmail dot com]

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

[jackyguo18 at hotmail dot com]

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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.