[Bug c++/106864] New: Unexpected capture of "constexpr int" variable inside lambda

[Bug c++/106864] New: Unexpected capture of "constexpr int" variable inside lambda

[a.elovikov at gmail dot com]

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

            Bug ID: 106864
           Summary: Unexpected capture of "constexpr int" variable inside
                    lambda
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: a.elovikov at gmail dot com
  Target Milestone: ---

void bad() {
  constexpr int x = 1;
  auto Outer = [&]() {
    auto L = [=]() {
      for (int i = 0; i < x; ++i) {
      }
    };
    static_assert(sizeof(L) == 1); // fails
  };
}

void good() {
  constexpr int x = 1;
  auto L = [=]() {
    for (int i = 0; i < x; ++i) {
    }
  };
  static_assert(sizeof(L) == 1);  // passes
}

Not sure if that's a bug from the standard conformance point of view, but I'd
expect the L not to capture constexpr variable in both cases.

Sizeof is one in both cases with clang and (MSVC v19.latest + "/std:c++latest
/c") on godbolt.

[Bug c++/106864] Unexpected capture of "constexpr int" variable inside lambda

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is just a missed optimization really.
Because GCC does the right thing inside the inner most lambda and it is
considered as a constexpr there still. But the inner lambda L has a capture
still.

You can see the missed optimization via:
void bad() {
  constexpr int x = 123;
  auto Outer = [&] [[gnu::noipa]] () {
    auto L = [=]  [[gnu::noipa]] () {
      for (int i = 0; i < x; ++i) { asm("":::"memory"); }

    };
    //static_assert(sizeof(L) == 1); // fails
    asm("":::"memory");
   L();
  };
  Outer();
    static_assert(sizeof(Outer) == 1); // fails
}

And look at the assembly for `bad()::{lambda()#1}::operator()() const` which
does the store before calling `bad()::{lambda()#1}::operator()()
const::{lambda()#1}::operator()() const`
But `bad()::{lambda()#1}::operator()() const::{lambda()#1}::operator()() const`
uses 123 always.
Even at -O2 and such.

[Bug c++/106864] Unexpected capture of "constexpr int" variable inside lambda

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Take:
void bad() {
  constexpr int x = 123;
  auto Outer = [&] [[gnu::noipa]] () {
    auto L = [=]  [[gnu::noipa]] () {
      const int *x1 = &x;
      for (int i = 0; i < *x1; ++i) { asm("":::"memory"); }
    };
    asm("":::"memory");
   L();
  };
  Outer();
}

void good() {
  constexpr int x = 123;
  auto L = [=] [[gnu::noipa]]() {
      const int *x1 = &x;
    for (int i = 0; i < *x1; ++i) {asm("":::"memory"); }    
  };
  L();
}

In the bad case, L is sizeof int and Outer is still 1. In good, it is sizeof
int.
This is for GCC and clang.

So I think GCC is just capturing and not removing constexpr after doing the
prop for constexpr. Which I think is just a missed optimization.