[Bug c++/92852] [8/9/10 Regression] location references block not in block tree

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-reduction

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's the &cout ADDR_EXPR of std::basic_ostream<char>::operator<< (&cout, _1);

 <addr_expr 0x7ffff3b2a0e0
    type <pointer_type 0x7ffff3cca5e8

$7 = <gimple_call 0x7ffff3751090>
std::basic_ostream<char>::operator<< (&cout, _1);

I think unnesting doesn't have any code rewriting BLOCK references to BLOCKs
outside of the nested function.  I guess we simply don't expect there to be
any...  but then we probably do not expect the outer function to vanish
without the inner vanishing as well and the checking code doesn't try to
"search" for the BLOCK in the outer function.

But the testcase must be somehow more "tricky" because the issue doesn't
reproduce with

int global;
void bar(int &, int);
void foo()
{
  int& l = global;
  auto x = [&l](auto && y) { bar(l, y); };
  x(1);
}

which shows a similar &global use in operator():

foo()::<lambda(auto:1&&)>::operator()<const int&> (const struct __lambda7 *
const __closure, const int & x)
{
  struct ostream & message_stream [value-expr: ((const struct __lambda7 *)
__closure)->__message_stream];

  _1 = *x;
  std::basic_ostream<char>::operator<< (&cout, _1);
}

vs.

foo()::<lambda(auto:1&&)>::operator()<int> (const struct __lambda0 * const
__closure, int & y)
{
  int & l [value-expr: ((const struct __lambda0 *) __closure)->__l];

  _1 = *y;
  bar (&global, _1);
}

so maybe the situation is all different.  Anyway, testcase needs reduction.
My limited C++ fu doesn't even allow to remove <tuple> use ;)  (that
variadic stuff)