https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127559
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, given the way the standard is worded, the lambda types might not even
noticed by the current walk:
template <typename T>
struct S {
T x;
int y;
};
template <typename T>
T
bar (T x)
{
return x;
}
template <typename T>
int
baz (const T &x)
{
return x.x ();
}
void
foo (int x, int y)
{
auto b = [&] { return x; };
S <decltype (b)> c = { b, 42 };
S <decltype (b)> d[2] = { { b, 42 }, { c, 42 } };
auto *p = &d[1];
#pragma omp target
if (baz (c) != 42 || baz (d[y]) () != 42 || baz (*foo (p)) () != 42)
__builtin_abort ();
}
int
main ()
{
foo (42, 0);
}
I really think this needs to be handled like a magic declare mapper for the
lambda types, handled during gimplification where declare mapper is (hopefully)
handled.
I'm afraid I don't have cycles to rewrite it that way.
I can tweak the above patch so that it handles something, or maybe just have it
as is, that handles the most common cases. Trying to map subobjects of
subobjects early (in the FE) is problematic because it could stand in the way
of actually mapping the whole objects etc.
