[Bug c++/99790] New: internal compiler error: in expand_expr_real_2

[Bug c++/99790] New: internal compiler error: in expand_expr_real_2

[antiro42 at gmail dot com]

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

            Bug ID: 99790
           Summary: internal compiler error: in expand_expr_real_2
           Product: gcc
           Version: 10.2.0
               URL: https://godbolt.org/z/PsMrafh9c
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: antiro42 at gmail dot com
  Target Milestone: ---

internal compiler error: in expand_expr_real_2, at expr.c:8701

Error is reproducible in compiler explorer with both gcc 10.2 and gcc trunk.
See attached URL for a minimal reproduction scenario.

The error seems to occur when trying to use the stored pointer to member in the
lambda.

I tried adding the suggested compiler flags but this did not influence the
result.

The code compiles fine in clang 11.

[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |8.5
                 CC|                            |jakub at gcc dot gnu.org
           Priority|P3                          |P2
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-03-26
            Summary|internal compiler error: in |[8/9/10/11 Regression]
                   |expand_expr_real_2          |internal compiler error: in
                   |                            |expand_expr_real_2

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Original testcase (we always want them in bugzilla rather than some external
site):
#include <iostream>
#include <string_view>
#include <array>

template<typename T>
struct Variable{
    std::string_view name;
    void (*set)(T*);
};

struct test{
    int var=0;

    struct metadata{
        static constexpr std::array<Variable<test>, 1> fields{
            Variable<test>{"var", 
                [](test* obj){obj->*(&test::var)=42;}
            }};
    };
};


int main(){
    test t;

    test::metadata::fields[0].set(&t);

    std::cout << t.var << "\n";
}

Reduced:
struct a {
  constexpr a(const char *) : b{}, c{} {}
  long b;
  char c;
};
using d = a;
struct e;
struct f;
template <int> struct m { typedef e g; };
template <int h> struct o {
  typename m<h>::g i;
  void operator[](long) const;
};
struct e {
  d j;
  void (*k)(f *);
};
struct f {
  int l;
  struct p {
    static constexpr o<1> fields{"", [](f *n) { n->*&f::l = 2; }};
  };
};
int main() { f::p::fields[0]; }

With -std=c++1z started to ICE with
r7-3811-g253abb2a156c6ea7d1631bbe9da32070fdfe901b

[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though, that doesn't make much sense, maybe r241137 instead?

[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Even more reduced:

struct A;
struct B { void (*fn) (A *); };
template <typename T>
int foo (const T &);
struct A { int a; static constexpr B b{[] (A *n) { n->*&A::a = 2; }}; };
int a = foo (A::b);

The problem seems to be that the lambda is genericized from
finish_lambda_function -> finish_function before the A class is finalized, so
    case PTRMEM_CST:
      /* By the time we get here we're handing off to the back end, so we don't
         need or want to preserve PTRMEM_CST anymore.  */
      *stmt_p = cplus_expand_constant (stmt);
doesn't do anything.

If PTRMEM_CSTs are the only thing, one possible fix could be
--- gcc/cp/cp-gimplify.c.jj     2021-03-20 17:01:59.791040946 +0100
+++ gcc/cp/cp-gimplify.c        2021-03-29 14:27:37.532223156 +0200
@@ -660,6 +660,14 @@ cp_gimplify_expr (tree *expr_p, gimple_s
       ret = GS_UNHANDLED;
       break;

+    case PTRMEM_CST:
+      *expr_p = cplus_expand_constant (*expr_p);
+      if (TREE_CODE (*expr_p) == PTRMEM_CST)
+       ret = GS_ERROR;
+      else
+       ret = GS_OK;
+      break;
+
     case RETURN_EXPR:
       if (TREE_OPERAND (*expr_p, 0)
          && (TREE_CODE (TREE_OPERAND (*expr_p, 0)) == INIT_EXPR
i.e. handle PTRMEM_CSTs not just during  genericization, but also during
gimplification where because we are unit at a time the classes should be better
complete already.

[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, static vars are unaffected by this, because c_parse_final_cleanups calls
lower_var_init on them and that expands the PTRMEM_CSTs in there.

[Bug c++/99790] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:953624089be3f51c2ebacba65be8521bf6ae8430

commit r11-7914-g953624089be3f51c2ebacba65be8521bf6ae8430
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 30 18:15:32 2021 +0200

    c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790]

    The following testcase ICEs (since the addition of inline var support),
    because the lambda contains PTRMEM_CST but finish_function is called for
the
    lambda quite early during parsing it (from finish_lambda_function) when
    the containing class is still incomplete.  That means that during
    genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but
    later nothing lowers it when the class is finalized.
    Using sizeof etc. on the class in such contexts is rejected by both g++ and
    clang++, and when the PTRMEM_CST appears e.g. in static var initializers
    rather than in functions, we handle it correctly because
c_parse_final_cleanups
    -> lower_var_init will handle those cplus_expand_constant when all classes
    are already finalized.

    The following patch fixes it by calling cplus_expand_constant again during
    gimplification, as we are now unconditionally unit at a time, I'd think
    everything that could be completed will be before we start gimplification.

    2021-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99790
            * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST.

            * g++.dg/cpp1z/pr99790.C: New test.

[Bug c++/99790] [8/9/10 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 Regression]      |[8/9/10 Regression]
                   |internal compiler error: in |internal compiler error: in
                   |expand_expr_real_2 since    |expand_expr_real_2 since
                   |r7-3811                     |r7-3811

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug c++/99790] [8/9/10 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:7cdd30b43a63832d6f908b2dd64bd19a0817cd7b

commit r10-9626-g7cdd30b43a63832d6f908b2dd64bd19a0817cd7b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 30 18:15:32 2021 +0200

    c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790]

    The following testcase ICEs (since the addition of inline var support),
    because the lambda contains PTRMEM_CST but finish_function is called for
the
    lambda quite early during parsing it (from finish_lambda_function) when
    the containing class is still incomplete.  That means that during
    genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but
    later nothing lowers it when the class is finalized.
    Using sizeof etc. on the class in such contexts is rejected by both g++ and
    clang++, and when the PTRMEM_CST appears e.g. in static var initializers
    rather than in functions, we handle it correctly because
c_parse_final_cleanups
    -> lower_var_init will handle those cplus_expand_constant when all classes
    are already finalized.

    The following patch fixes it by calling cplus_expand_constant again during
    gimplification, as we are now unconditionally unit at a time, I'd think
    everything that could be completed will be before we start gimplification.

    2021-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99790
            * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST.

            * g++.dg/cpp1z/pr99790.C: New test.

[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
            Summary|[8/9/10 Regression]         |[8/9 Regression] internal
                   |internal compiler error: in |compiler error: in
                   |expand_expr_real_2 since    |expand_expr_real_2 since
                   |r7-3811                     |r7-3811

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.3 too.

[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:41c21d0e51e82c8303a8ca03c69546f86caa1b92

commit r9-9440-g41c21d0e51e82c8303a8ca03c69546f86caa1b92
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 30 18:15:32 2021 +0200

    c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790]

    The following testcase ICEs (since the addition of inline var support),
    because the lambda contains PTRMEM_CST but finish_function is called for
the
    lambda quite early during parsing it (from finish_lambda_function) when
    the containing class is still incomplete.  That means that during
    genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but
    later nothing lowers it when the class is finalized.
    Using sizeof etc. on the class in such contexts is rejected by both g++ and
    clang++, and when the PTRMEM_CST appears e.g. in static var initializers
    rather than in functions, we handle it correctly because
c_parse_final_cleanups
    -> lower_var_init will handle those cplus_expand_constant when all classes
    are already finalized.

    The following patch fixes it by calling cplus_expand_constant again during
    gimplification, as we are now unconditionally unit at a time, I'd think
    everything that could be completed will be before we start gimplification.

    2021-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99790
            * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST.

            * g++.dg/cpp1z/pr99790.C: New test.

    (cherry picked from commit 7cdd30b43a63832d6f908b2dd64bd19a0817cd7b)

[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:718c32a39895ea12ff79f05d6001d7401e6e7e11

commit r8-10903-g718c32a39895ea12ff79f05d6001d7401e6e7e11
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 30 18:15:32 2021 +0200

    c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790]

    The following testcase ICEs (since the addition of inline var support),
    because the lambda contains PTRMEM_CST but finish_function is called for
the
    lambda quite early during parsing it (from finish_lambda_function) when
    the containing class is still incomplete.  That means that during
    genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but
    later nothing lowers it when the class is finalized.
    Using sizeof etc. on the class in such contexts is rejected by both g++ and
    clang++, and when the PTRMEM_CST appears e.g. in static var initializers
    rather than in functions, we handle it correctly because
c_parse_final_cleanups
    -> lower_var_init will handle those cplus_expand_constant when all classes
    are already finalized.

    The following patch fixes it by calling cplus_expand_constant again during
    gimplification, as we are now unconditionally unit at a time, I'd think
    everything that could be completed will be before we start gimplification.

    2021-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99790
            * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST.

            * g++.dg/cpp1z/pr99790.C: New test.

    (cherry picked from commit 7cdd30b43a63832d6f908b2dd64bd19a0817cd7b)

[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tilin97 at yandex dot ru

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 95292 has been marked as a duplicate of this bug. ***