[Bug c++/107514] New: quick crash of gcc due to noexcept specification

janezz55 at gmail dot com gcc-bugzilla@gcc.gnu.org
Thu Nov 3 08:36:00 GMT 2022


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

            Bug ID: 107514
           Summary: quick crash of gcc due to noexcept specification
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: janezz55 at gmail dot com
  Target Milestone: ---

The noexcept specification is probably c++ non-complaint, but still causes a
crash:

constexpr void assign_tuple(auto& t, auto&& ...a)
  noexcept(noexcept(
      []<auto ...I>(std::index_sequence<I...>)
        noexcept(noexcept(
            ((std::get<I>(t) = std::forward<decltype(a)>(a)), ...)
          )
        )
      {
      }(std::make_index_sequence<sizeof...(a)>())
    )
  )
{
  [&]<auto ...I>(std::index_sequence<I...>)
    noexcept(noexcept(((std::get<I>(t) = std::forward<decltype(a)>(a)), ...)))
  {
    ((std::get<I>(t) = std::forward<decltype(a)>(a)), ...);
  }(std::make_index_sequence<sizeof...(a)>());
}

prog.cc: In instantiation of 'assign_tuple<std::tuple<int, int, int>, int, int,
int>(std::tuple<int, int, int>&, int&&, int&&,
int&&)::<lambda(std::index_sequence<I ...>)> [with auto ...I = {0, 1, 2};
std::index_sequence<I ...> = std::integer_sequence<long unsigned int, 0, 1,
2>]':
prog.cc:21:4:   required from 'constexpr void assign_tuple(auto:1&, auto:2&&
...) [with auto:1 = std::tuple<int, int, int>; auto:2 = {int, int, int}]'
prog.cc:29:15:   required from here
prog.cc:18:73: internal compiler error: Segmentation fault
   18 |     noexcept(noexcept(((std::get<I>(t) = std::forward<decltype(a)>(a)),
...)))
      |                      
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~

The source is here:
https://wandbox.org/permlink/alJJGFEkTE8b7EXn

I can't provide anything else, since I typed it in over at wandbox. I suspect
the bug is a duplicate anyway. clang does not crash while compiling the
snippet.


More information about the Gcc-bugs mailing list