[Bug c++/97966] New: maybe_instantiate_noexcept

[Bug c++/97966] New: maybe_instantiate_noexcept

[jonathan.k at qspark dot co]

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

            Bug ID: 97966
           Summary: maybe_instantiate_noexcept
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jonathan.k at qspark dot co
  Target Milestone: ---

Getting the following backtrace while compiling using gcc 10.2 with c++17 on
fedora 23 os:

11:09:02  0x5fe0c0 maybe_instantiate_noexcept(tree_node*, int)
11:09:02        ../.././gcc/cp/pt.c:25346
11:09:02  0x6c5f9a mark_used(tree_node*, int)
11:09:02        ../.././gcc/cp/decl2.c:5516
11:09:02  0x77cd97 instantiate_class_template_1
11:09:02        ../.././gcc/cp/pt.c:11819
11:09:02  0x77d7a2 instantiate_class_template(tree_node*)
11:09:02        ../.././gcc/cp/pt.c:12120
11:09:02  0x7ad0ed complete_type(tree_node*)
11:09:02        ../.././gcc/cp/typeck.c:137
11:09:02  0x7ad0ed complete_type(tree_node*)
11:09:02        ../.././gcc/cp/typeck.c:111
11:09:02  0x77cdec instantiate_class_template_1
11:09:02        ../.././gcc/cp/pt.c:11906
11:09:02  0x77d7a2 instantiate_class_template(tree_node*)
11:09:02        ../.././gcc/cp/pt.c:12120
11:09:02  0x7ad0ed complete_type(tree_node*)
11:09:02        ../.././gcc/cp/typeck.c:137
11:09:02  0x7ad0ed complete_type(tree_node*)
11:09:02        ../.././gcc/cp/typeck.c:111
11:09:02  0x730ef3 cp_parser_nested_name_specifier_opt
11:09:02        ../.././gcc/cp/parser.c:6642
11:09:02  0x7201ca cp_parser_constructor_declarator_p
11:09:02        ../.././gcc/cp/parser.c:28667
11:09:02  0x7201ca cp_parser_decl_specifier_seq
11:09:02        ../.././gcc/cp/parser.c:14349
11:09:02  0x743485 cp_parser_single_declaration
11:09:02        ../.././gcc/cp/parser.c:29421
11:09:02  0x7437fd cp_parser_template_declaration_after_parameters
11:09:02        ../.././gcc/cp/parser.c:29084
11:09:02  0x743daa cp_parser_explicit_template_declaration
11:09:02        ../.././gcc/cp/parser.c:29350
11:09:02  0x746c89 cp_parser_declaration
11:09:02        ../.././gcc/cp/parser.c:13387
11:09:02  0x746872 cp_parser_toplevel_declaration
11:09:02        ../.././gcc/cp/parser.c:13466
11:09:02  0x746872 cp_parser_declaration_seq_opt
11:09:02        ../.././gcc/cp/parser.c:13314
11:09:02  0x746872 cp_parser_namespace_body
11:09:02        ../.././gcc/cp/parser.c:19727

Attached a generated ii file.
Compilation flag:
/usr/local/bin/g++ <include-directives> -save-temps=obj -std=c++17 -Wall
-Wextra -Wno-unused-parameter -Werror -O3 -g -Wfatal-errors
-ftemplate-depth=1800 -ftrack-macro-expansion=1 -static-libstdc++ -fpic -o
<cmake-build-path>/Exceptions.cpp.o -c <source-path>/Exceptions.cpp

If you can also provide a code workaround I can use if this is a known issue
then it would be great.

Thanks in advance,
Jonathan

[Bug c++/97966] maybe_instantiate_noexcept

[jonathan.k at qspark dot co]

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

--- Comment #1 from jonathan.k at qspark dot co ---
Created attachment 49617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49617&action=edit
ii file which can be used to reproduce the bug

[Bug c++/97966] [10/11 Regression] maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-11-30
     Ever confirmed|0                           |1
   Target Milestone|---                         |10.3
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org
            Summary|maybe_instantiate_noexcept  |[10/11 Regression]
                   |                            |maybe_instantiate_noexcept
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r272586 so mine.

[Bug c++/97966] [10/11 Regression] maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Reduced (but invalid?):

// PR c++/97966

template <int>
struct S {
  __attribute__((used)) S() noexcept(noexcept(this->foo()));
  void foo();
};

void
g ()
{
  S<1> s;
}

[Bug c++/97966] [10/11 Regression] maybe_instantiate_noexcept

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/97966] [10/11 Regression] maybe_instantiate_noexcept

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

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

commit r11-6848-gbca467e56fe111fa6d876656c60d5704065e83fe
Author: Marek Polacek <polacek@redhat.com>
Date:   Tue Jan 12 16:16:44 2021 -0500

    c++: ICE with delayed noexcept and attribute used [PR97966]

    Another ICE with delayed noexcept parsing, but a bit gnarlier.

    A function definition marked with __attribute__((used)) ought to be
    emitted even when it is not referenced in the TU.  For a member function
    template marked with __attribute__((used)) this means that it will
    be instantiated: in instantiate_class_template_1 we have

    11971               /* Instantiate members marked with attribute used.  */
    11972               if (r != error_mark_node && DECL_PRESERVE_P (r))
    11973                 mark_used (r);

    It is not so surprising that this doesn't work well with delayed
    noexcept parsing: when we're processing the function template we delay
    the parsing, so the member "foo" is found, but then when we're
    instantiating it, "foo" hasn't yet been seen, which creates a
    discrepancy and a crash ensues.  "foo" hasn't yet been seen because
    instantiate_class_template_1 just loops over the class members and
    instantiates right away.

    To make it work, this patch uses a vector to keep track of members
    marked with attribute used and uses it to instantiate such members
    only after we're done with the class; in particular, after we have
    called finish_member_declaration for each member.  And we ought to
    be verifying that we did emit such members, so I've added a bunch
    of dg-finals.

    gcc/cp/ChangeLog:

            PR c++/97966
            * pt.c (instantiate_class_template_1): Instantiate members
            marked with attribute used only after we're done instantiating
            the class.

    gcc/testsuite/ChangeLog:

            PR c++/97966
            * g++.dg/cpp0x/noexcept63.C: New test.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11 Regression]          |[10 Regression]
                   |maybe_instantiate_noexcept  |maybe_instantiate_noexcept

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed on trunk so far.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.3                        |10.4

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6f45079013256ed730c92bf35af4e6394cb5a2c0

commit r10-9683-g6f45079013256ed730c92bf35af4e6394cb5a2c0
Author: Marek Polacek <polacek@redhat.com>
Date:   Fri Apr 9 18:31:12 2021 -0400

    c++: ICE with delayed noexcept and attribute used [PR97966]

    Another ICE with delayed noexcept parsing, but a bit gnarlier.

    A function definition marked with __attribute__((used)) ought to be
    emitted even when it is not referenced in the TU.  For a member function
    template marked with __attribute__((used)) this means that it will
    be instantiated: in instantiate_class_template_1 we have

    11971               /* Instantiate members marked with attribute used.  */
    11972               if (r != error_mark_node && DECL_PRESERVE_P (r))
    11973                 mark_used (r);

    It is not so surprising that this doesn't work well with delayed
    noexcept parsing: when we're processing the function template we delay
    the parsing, so the member "foo" is found, but then when we're
    instantiating it, "foo" hasn't yet been seen, which creates a
    discrepancy and a crash ensues.  "foo" hasn't yet been seen because
    instantiate_class_template_1 just loops over the class members and
    instantiates right away.

    To make it work, this patch uses a vector to keep track of members
    marked with attribute used and uses it to instantiate such members
    only after we're done with the class; in particular, after we have
    called finish_member_declaration for each member.  And we ought to
    be verifying that we did emit such members, so I've added a bunch
    of dg-finals.

    gcc/cp/ChangeLog:

            PR c++/97966
            * pt.c (instantiate_class_template_1): Instantiate members
            marked with attribute used only after we're done instantiating
            the class.

    gcc/testsuite/ChangeLog:

            PR c++/97966
            * g++.dg/cpp0x/noexcept63.C: New test.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed in GCC 10.4 too.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This breaks the build with older compilers:

../../src/gcc/cp/pt.c: In function 'tree_node*
instantiate_class_template_1(tree)':
../../src/gcc/cp/pt.c:12137:17: error: range-based 'for' loops are not allowed
in C++98 mode

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Argh!  Sorry about that, will fix.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Marek Polacek
<mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:1004d3bb5e590a2cc3d22bc9fb11d3bf4978a982

commit r10-9695-g1004d3bb5e590a2cc3d22bc9fb11d3bf4978a982
Author: Marek Polacek <polacek@redhat.com>
Date:   Sun Apr 11 16:58:09 2021 -0400

    c++: Use FOR_EACH_VEC_ELT instead of range-based for loop.

    gcc/cp/ChangeLog:

            PR c++/97966
            * pt.c (instantiate_class_template_1): Use FOR_EACH_VEC_ELT instead
            of range-based for loop.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be fixed, sorry again for the breakage.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Yes, thanks for the quick turnaround.