[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-03-03

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
Actually, comment #3 has it mostly :

here is the frame layout from the test case:

FRAME type decl
boost::asio::g<int,
void(|ds|int)>::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame
   {
     void (*)(|ds|boost::asio::g<int,
void(|ds|int)>::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)_Coro_resume_fn)(|ds|boost::asio::g<int,
void(|ds|int)>::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)
    void (*)(|ds|boost::asio::g<int,
void(|ds|int)>::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)_Coro_destroy_fn)(|ds|boost::asio::g<int,
void(|ds|int)>::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)
    boost::asio::d::promise_type _Coro_promise
     std::__n4861::coroutine_handle<boost::asio::d::z>_Coro_self_handle
     int ai
     short unsigned int _Coro_resume_index
     bool _Coro_frame_needs_free
     bool _Coro_initial_await_resume_called
     std::__n4861::suspend_always Is_1_1
     boost::asio::d::ae::await_transform::y Aw0_2_3
     boost::asio::g<int, void(|ds|int)>::ab::._anon_5 D.10232_2_3 
     boost::asio::d::ae::final_suspend::u Fs_1_4
  }

in the second case, 

     boost::asio::g<int, void(|ds|int)>::ab::._anon_5 D.10233_2_3

This is because I have used the DECL_UID as a convenient way to generate a
unique nane that is also very handy for debugging since it refers back to the
original function.

However, DECL_UIDs are not stable between TUs, obviously, since it depends on
how many there are before the specific case.

So .. for promotion of target expression temporaries to frame vars, one of:
 - a) we need to find a different way to name them
 - b) if it is permissible for an unnamed decl to have a DECL_VALUE_EXPR ()
perhaps the process can be adjusted to avoid naming these cases (although it
does assist in debuggability).