[Bug c++/107897] New: [13 Regression] ICE in verify_curr_properties, at passes.cc:2201

[Bug c++/107897] New: [13 Regression] ICE in verify_curr_properties, at passes.cc:2201

[gscfq@t-online.de]

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

            Bug ID: 107897
           Summary: [13 Regression] ICE in verify_curr_properties, at
                    passes.cc:2201
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started between 20221030 and 20221106,
with file g++.dg/cpp2a/concepts-lambda3.C :


$ gcc-13-20221127 -c concepts-lambda3.C -std=c++20 -flto -fno-inline
concepts-lambda3.C:40:13: error: mangling of 'main(int,
char**)::<lambda(auto:5)> [with auto:5 = int]' as
'_ZZ4mainENKUlT_E1_clIiEEDaS_' conflicts with a previous mangle
   40 |   auto a0 = [](IsNotLarge auto a) { return [](auto b){ return b; }; };
      |             ^
concepts-lambda3.C:37:3: note: previous mangling 'int main(int,
char**)::<lambda(auto:3)>::_ZZ4mainENKUlT_E1_clIiEEDaS_(int) const'
   37 |   [](auto t) requires true { return t; }(5);
      |   ^
concepts-lambda3.C:40:13: note: a later '-fabi-version=' (or =0) avoids this
error with a change in mangling
   40 |   auto a0 = [](IsNotLarge auto a) { return [](auto b){ return b; }; };
      |             ^
during IPA pass: targetclone
concepts-lambda3.C:63:1: internal compiler error: in verify_curr_properties, at
passes.cc:2201
   63 | }
      | ^
0x10c1cb5 verify_curr_properties
        ../../gcc/passes.cc:2201
0x10c23dd do_per_function
        ../../gcc/passes.cc:1701

[Bug c++/107897] [13 Regression] ICE in verify_curr_properties, at passes.cc:2201

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Keywords|                            |ABI, c++-lambda

[Bug c++/107897] [13 Regression] ICE in verify_curr_properties, at passes.cc:2201

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(gdb) p fn->curr_properties
$4 = 92431

that looks like garbage.  We likely cut off processing one of the functions
because of the error (and failed to initialize ->curr_properties when
allocating struct function).  In particular we gate off build_ssa_passes
but not consistently all other small IPA passes and target_clone is the
only one requiring any SSA/CFG properties.

I'm testing a patch for the ICE-after-error, the error remains.

[Bug c++/107897] [13 Regression] ICE in verify_curr_properties, at passes.cc:2201

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:5894a8179687b7028d093584102d204af422cfd3

commit r13-4384-g5894a8179687b7028d093584102d204af422cfd3
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Nov 29 08:43:55 2022 +0100

    ipa/107897 - avoid property verification ICE after error

    The target clone pass is the only small IPA pass that doesn't disable
    itself after errors but has properties whose verification can fail
    because we cut off build SSA passes after errors.

            PR ipa/107897
            * multiple_target.cc (pass_target_clone::gate): Disable
            after errors.

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|ice-on-valid-code           |rejects-valid
   Last reconfirmed|                            |2022-11-29
     Ever confirmed|0                           |1
            Summary|[13 Regression] ICE in      |[13 Regression] mangling
                   |verify_curr_properties, at  |conflicts with a previous
                   |passes.cc:2201              |mangle

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I fixed the ICE but the mangling error remains.

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[13 Regression] mangling    |[13 Regression] mangling
                   |conflicts with a previous   |conflicts with a previous
                   |mangle                      |mangle since r13-3601
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |nathan at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r13-3601-g2b0e81d5cc2f7e1d773f6c502bd65b097f392675

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The error can be certainly worked around with -fabi-compat-version=18, but I
wonder
if we just shouldn't disable mangling aliases for decls where
write_closure_type_name
has been called and LAMBDA_EXPR_SCOPE_SIG_DISCRIMINATOR !=
LAMBDA_EXPR_SCOPE_ONLY_DISCRIMINATOR.  Because the mangling change doesn't look
like mangle this differently, but use different numbering scheme in the same
mangling.
If yes, it could be arranged by
  if ((LAMBDA_EXPR_SCOPE_SIG_DISCRIMINATOR (lambda)
       != LAMBDA_EXPR_SCOPE_ONLY_DISCRIMINATOR (lambda))
      && abi_warn_or_compat_version_crosses (18))
    G.need_abi_warning = true;
not setting just the G.need_abi_warning flag but some new flag in G which would
disable creation of the mangling alias.

Thoughts on that?

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asolokha at gmx dot com

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
*** Bug 108971 has been marked as a duplicate of this bug. ***

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5

commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
Author: Jason Merrill <jason@redhat.com>
Date:   Mon Mar 6 15:33:45 2023 -0500

    c++: lambda mangling alias issues [PR107897]

    In 107897, by the time we are looking at the mangling clash, the
    alias has already been removed from the symbol table by analyze_functions,
    so we can't look at n->cpp_implicit_alias.  So just assume that it's an
    alias if it's internal.

    In 108887 the problem is that removing the mangling alias from the symbol
    table confuses analyze_functions, because it ended up as first_analyzed
    somehow, so it becomes a dangling pointer.  So instead we call reset()
    to neutralize the alias.  To make this work for variables, I needed to move
    reset() from cgraph_node to symtab_node.

            PR c++/107897
            PR c++/108887

    gcc/ChangeLog:

            * cgraph.h: Move reset() from cgraph_node to symtab_node.
            * cgraphunit.cc (symtab_node::reset): Adjust.  Also call
            remove_from_same_comdat_group.

    gcc/cp/ChangeLog:

            * decl2.cc (record_mangling): Use symtab_node::reset.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported.
            * g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed.