[Bug c++/94751] New: [9/10] ICE on invalid code in maybe_instantiate_noexcept

[Bug c++/94751] New: [9/10] ICE on invalid code in maybe_instantiate_noexcept

[sss@li-snyder.org]

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

            Bug ID: 94751
           Summary: [9/10] ICE on invalid code in
                    maybe_instantiate_noexcept
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sss@li-snyder.org
  Target Milestone: ---

hi -

gcc version:

gcc version 10.0.1 20200329 (experimental) (GCC) 

ICEs on the following (invalid) input:

-- x.cc -----------------------------------------------------
struct  Algorithm
{
  Algorithm( float );
};


template <class BASE>
struct ToolWithConstants
  : public Algorithm
{
  using Algorithm::Algorithm;

  struct Constant
  {
    Constant (int name);
  };

  Constant c { "order" };
};

class unique_ptr {};

unique_ptr make()
{
  return unique_ptr (new ToolWithConstants<Algorithm> (10.5));
}

------------------------------------------------------------


like this:

[sss@karma rootaccess]$ g++ -c x.cc
x.cc: In function ‘unique_ptr make()’:
x.cc:25:60: internal compiler error: Segmentation fault
   25 |   return unique_ptr (new ToolWithConstants<Algorithm> (10.5));
      |                                                            ^
0xc4fe4f crash_signal
        /home/sss/gcc/gcc/gcc/toplev.c:328
0x7f4d24bf8ebf ???
       
/usr/src/debug/glibc-2.29-51-g845278f2c6/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x759eff maybe_instantiate_noexcept(tree_node*, int)
        /home/sss/gcc/gcc/gcc/cp/pt.c:25032
0x6b8388 mark_used(tree_node*, int)
        /home/sss/gcc/gcc/gcc/cp/decl2.c:5512
0x644892 build_over_call
        /home/sss/gcc/gcc/gcc/cp/call.c:9048
0x646ade build_new_method_call_1
        /home/sss/gcc/gcc/gcc/cp/call.c:10338
0x647796 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
        /home/sss/gcc/gcc/gcc/cp/call.c:10413
0x647796 build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
        /home/sss/gcc/gcc/gcc/cp/call.c:9814
0x6cec5f build_new_1
        /home/sss/gcc/gcc/gcc/cp/init.c:3588
0x6cf9f8 build_new(unsigned int, vec<tree_node*, va_gc, vl_embed>**,
tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, int, int)
        /home/sss/gcc/gcc/gcc/cp/init.c:3905
0x729a37 cp_parser_new_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:8825
0x72a057 cp_parser_unary_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:8418
0x706b1a cp_parser_binary_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:9554
0x7081ce cp_parser_assignment_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:9859
0x70a668 cp_parser_parenthesized_expression_list
        /home/sss/gcc/gcc/gcc/cp/parser.c:7981
0x70ada2 cp_parser_functional_cast
        /home/sss/gcc/gcc/gcc/cp/parser.c:29572
0x721f24 cp_parser_postfix_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:7180
0x706b1a cp_parser_binary_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:9554
0x7081ce cp_parser_assignment_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:9859
0x7084e2 cp_parser_expression
        /home/sss/gcc/gcc/gcc/cp/parser.c:10027
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.



A crash is also observed with a 20200424 version as well as

gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC) 


thanks,
sss

[Bug c++/94751] [9/10] ICE on invalid code in maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |9.4
   Last reconfirmed|                            |2020-04-24
     Ever confirmed|0                           |1
           Keywords|                            |ice-on-invalid-code

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r9-6097-g9d35a27a8353b57ed11fa1cb7d747edf1c4faa01

[Bug c++/94751] [9/10 Regression] ICE on invalid code in maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
We now error_mark_node around for a longer time, so we need to handle it. 
Taking.

[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept

[rguenth at gcc dot gnu.org]

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

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

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

[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---

Reduced code is:

template <int a> struct c { static constexpr int d = a; };
template <bool, typename> struct e;
template <typename f> struct e<true, f> { typedef f g; };
template <typename f> f aa();
class h {
public:
  template <typename i, typename... j> void ab(i *, j...) { i(j()...); }
};
template <typename> using k = h;
template <typename> class l : public k<int> {};
template <typename> struct m;
template <typename f> struct m<l<f>> {
  using n = l<f>;
  using o = f *;
  template <typename i> using p = l<i>;
  template <typename i, typename... j> static void ab(n ac, i q, j...) {
    ac.ab(q, j()...);
  }
};
template <typename...> struct r;
struct s : m<l<r<float>>> {
  struct ad {
    typedef p<r<float>> ae;
  };
};
template <typename> struct af;
template <long, typename f> using ag = typename af<f>::g;
template <typename> class ah {};
template <typename ai, typename... u> struct af<ah<ai, u...>> { typedef ai g;
};
template <long aj, typename... v> ag<aj, ah<v...>> ak(ah<v...>);
class al {
public:
  template <typename w> void operator=(w);
};
struct am {
  struct an {
    s::o ao;
  };
  struct : s::ad::ae, an {
  } ap;
};
template <typename, typename = int> class x : am {
public:
  template <typename... j> s aq(j &&...);
};
template <typename f, typename ar>
template <typename... j>
s x<f, ar>::aq(j &&...) {
  s::ab(ap, ap.ao, aa<j>()...);
}
template <typename...> class as;
template <typename... at> struct r {
  int au;
  r(at...);
  template <typename av> void aw(av);
};
class y {
public:
  static constexpr struct {
    template <typename ax> typename e<c<false>::d, ax>::g ay();
    template <typename ax> static typename e<!c<false>::d, ax>::g ay();
  } az{};
};
template <int ba> struct z {
  static void bb() {
    ah<al> b;
    ak<ba>(b) = y::az.ay<int>;
  }
};
template <typename bc, typename bd> void be(bc, bd) { z<0>::bb; }
template <typename... at> r<at...>::r(at...) { aw(y::az); }
template <typename... at> template <typename av> void r<at...>::aw(av ac) {
  be(au, ac);
}
template <typename ax> class as<ax> {
public:
  as &bf();
  x<int> bg;
};
template <typename ax> as<ax> &as<ax>::bf() {
  ax t;
  bg.aq(t);
}
template <typename... at> as<at...> bh(at...);
auto bi = bh(1.0f).bf();

[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I posted a patch for this which fixes this test too.

[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Actually Comment 3 test is unrelated to the original issue here.  Comment 3
will be fixed by my PR98659 fix, but not the original issue.

[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566369.html

Also note https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98352#c2

[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:d4e0bdbc036644401f9de49f594b2bb16b287381

commit r11-7835-gd4e0bdbc036644401f9de49f594b2bb16b287381
Author: Marek Polacek <polacek@redhat.com>
Date:   Fri Mar 5 15:46:50 2021 -0500

    c++: ICE on invalid with inheriting constructors [PR94751]

    This is an ICE on invalid where we crash because since r269032 we
    keep error_mark_node around instead of using noexcept_false_spec
    when things go wrong; see the walk_field_subobs hunk.

    We crash in deduce_inheriting_ctor which calls synthesized_method_walk
    to deduce the exception-specification, but fails to do so in this case,
    because the testcase is invalid so get_nsdmi returns error_mark_node for
    the member 'c', and per r269032 the error_mark_node propagates back to
    deduce_inheriting_ctor which subsequently calls build_exception_variant
    whereon we crash.  I think we should return early if the deduction fails
    and I decided to call mark_used to get an error right away instead of
    hoping that it would get called later.  My worry is that we could forget
    that there was an error and think that we just deduced noexcept(false).

    And then I noticed that the test still crashes in C++98.  Here again we
    failed to deduce the exception-specification in implicitly_declare_fn,
    but nothing reported an error between synthesized_method_walk and the
    assert.  Well, not much we can do except calling synthesized_method_walk
    again, this time in the verbose mode and making sure that we did get an
    error.

    gcc/cp/ChangeLog:

            PR c++/94751
            * call.c (build_over_call): Maybe call mark_used in case
            deduce_inheriting_ctor fails and return error_mark_node.
            * cp-tree.h (deduce_inheriting_ctor): Adjust declaration.
            * method.c (deduce_inheriting_ctor): Return bool if the deduction
            fails.
            (implicitly_declare_fn): If raises is error_mark_node, call
            synthesized_method_walk with diag being true.

    gcc/testsuite/ChangeLog:

            PR c++/94751
            * g++.dg/cpp0x/inh-ctor37.C: New test.

[Bug c++/94751] [9/10/11 Regression] ICE on invalid code in maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org]

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

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

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

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