From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id B9E5538582BD; Wed, 22 Feb 2023 15:18:30 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B9E5538582BD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677079110;
	bh=LHOvvcWTskKLPKOmjINfG7oKDYlkKb/tXP0vihsCaKY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Q690ZGIq4CgzbGRAYNgkgEBp/OlsrA4hCCB0UxHmTw+veWlxT8qM44MJOvu6+XKLI
	 s9DtTOeAnmoGGQtSjNKNpjvfBhQ+iLnJ8Z84CcYJfU21IcBzzLDX1RU0+x1azC6sYW
	 85zYsMo7MOj7EPS5n3DvoYRn2zvjh05Uauw2RnsI=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/108887] [13 Regression] ICE in
 process_function_and_variable_attributes since r13-3601
Date: Wed, 22 Feb 2023 15:18:29 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108887-4-xCEkSAB3dx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108887-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108887-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The ICE is actually in cgraph code, so it might as well be just some latent
cgraph bug triggered by the C++ changes.
What I see is that first_analyzed is set to a cgraph node for
_ZZN27LinkPaginationTimelineModel12fillTimelineEvENKUlP15AbstractAccountE0_=
clES1_
But that node is then removed in:
#0  0x00007ffff7a4ec8f in __memset_evex_unaligned_erms () from /lib64/libc.=
so.6
#1  0x000000000094ec0b in ggc_free (p=3D0x7fffe9e93bb0) at
../../gcc/ggc-page.cc:1630
#2  0x0000000000a24fb6 in symbol_table::release_symbol (this=3D0x7fffea1300=
00,
node=3D<error reading variable: Cannot access memory at address
0xa5a5a5a5a5a5a5c5>)
    at ../../gcc/cgraph.h:2853
#3  0x0000000000a1d498 in cgraph_node::remove (this=3D<error reading variab=
le:
Cannot access memory at address 0xa5a5a5a5a5a5a5c5>) at
../../gcc/cgraph.cc:1974
#4  0x0000000000a08369 in symtab_node::remove (this=3D<error reading variab=
le:
Cannot access memory at address 0xa5a5a5a5a5a5a5c5>) at ../../gcc/symtab.cc=
:481
#5  0x00000000005866e4 in record_mangling (decl=3D<function_decl 0x7fffea31=
9200
operator()>, need_warning=3Dtrue) at ../../gcc/cp/decl2.cc:4751
#6  0x00000000005f5d5d in mangle_decl (decl=3D<function_decl 0x7fffea319200
operator()>) at ../../gcc/cp/mangle.cc:4196
#7  0x0000000001456c70 in decl_assembler_name (decl=3D<function_decl
0x7fffea319200 operator()>) at ../../gcc/tree.cc:743
#8  0x0000000001457234 in assign_assembler_name_if_needed (t=3D<function_de=
cl
0x7fffea319200 operator()>) at ../../gcc/tree.cc:858
#9  0x0000000000a2cf4d in cgraph_node::analyze (this=3D<cgraph_node * const
0x7fffea144990 "operator()"/9>) at ../../gcc/cgraphunit.cc:669
#10 0x0000000000a2effe in analyze_functions (first_time=3Dtrue) at
../../gcc/cgraphunit.cc:1238
but nothing updates first_analyzed.

record_mangling has:
  /* If this is already an alias, remove the alias, because the real
     decl takes precedence.  */
  if (*slot && DECL_ARTIFICIAL (*slot) && DECL_IGNORED_P (*slot))
    if (symtab_node *n =3D symtab_node::get (*slot))
      if (n->cpp_implicit_alias)
        {
          n->remove ();
          *slot =3D NULL_TREE;
        }

So, to some extent this is related to PR107897.
The ICE is obviously gone with -fabi-compat-version=3D0 and so if we wouldn=
't
emit compatibility aliases for lambdas based on PR107897, this issue would =
be
latent again.=