public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "peeceseven at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/102987] New: [9, 10, 11, trunk] Segfault when error or warning should trigger with combination.
Date: Thu, 28 Oct 2021 12:49:20 +0000	[thread overview]
Message-ID: <bug-102987-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 102987
           Summary: [9,10,11,trunk] Segfault when error or warning should
                    trigger with combination.
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: peeceseven at gmail dot com
  Target Milestone: ---

Created attachment 51690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51690&action=edit
creduced sample code.

I am using GCC 11.1 locally. When I detected the issue, I ran creduce to find a
sample test case. Then I used it on godbolt.org to see what versions were
affected. The latest version of GCC I found that didn’t have this issue was
8.5.

It seems to me anything you put in function g that should cause an error or
warning causes the segfault.


Sample 1: This should be erroring because lacking a return value, or warn that
this is unused.
// begin code
// https://godbolt.org/z/3TxGsGbYr
struct a {
  bool b();
};
template <typename c> struct d : c {
  c::e;
  using f = d;
  constexpr f g(decltype(e.b())) { this; }
};
struct h {
  a e;
};
using i = d<h>;
auto j = i{}.g(1);
// end code
// begin error output
<source>:6:5: warning: access declarations are deprecated in favour of
using-declarations; suggestion: add the 'using' keyword [-Wdeprecated]
    6 |     c::e;
      |     ^
'
Segmentation fault
    8 |     constexpr f g(decltype(e.b())) { this; }
      |                                            ^
0x2006499 internal_error(char const*, ...)
        ???:0
0x2022991 pp_format(pretty_printer*, text_info*)
        ???:0
0x2023010 pp_format_verbatim(pretty_printer*, text_info*)
        ???:0
0x20230f1 pp_verbatim(pretty_printer*, char const*, ...)
        ???:0
0x20050d1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
        ???:0
0x2008306 error_at(rich_location*, char const*, ...)
        ???:0
0x8d2035 finish_function(bool)
        ???:0
0xa45f47 instantiate_decl(tree_node*, bool, bool)
        ???:0
0x1501d13 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
        ???:0
0x150275c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
        ???:0
0x1505ef5 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, false,
default_hash_traits<tree_node*> >*))
        ???:0
0xb20690 store_init_value(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int)
        ???:0
0x8d3fa9 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
        ???:0
0xa0c105 c_parse_file()
        ???:0
0xb93132 c_common_parse_file()
        ???:0
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.
Compiler returned: 1
// end error output

Sample 2: This is using -Wunused-but-set-variable. Should be warning on the
unused variable set instead of segfault.  If we remove the
-Wunused-but-set-variable this compiles normally. This is closer to what my
actual code. I had two unused variables and I had this warning on.

// begin code
// https://godbolt.org/z/K4Ma5qbYo
struct a {
  bool b();
};
template <typename c>
struct d : c {
  using c::e;
  using f = d;
  constexpr f g(decltype(e.b())) {
    auto r = *this;
    const auto a = r.e; //-Wunused-but-set-variable
    return r;}
};
struct h {
  a e;
};
using i = d<h>;
auto j = i{}.g(1);
// end code
// begin error output
Segmentation fault
   11 |         return r;}
      |                  ^
0x2006499 internal_error(char const*, ...)
        ???:0
0x2022991 pp_format(pretty_printer*, text_info*)
        ???:0
0x2023010 pp_format_verbatim(pretty_printer*, text_info*)
        ???:0
0x20230f1 pp_verbatim(pretty_printer*, char const*, ...)
        ???:0
0x20050d1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
        ???:0
0x2005c75 warning_at(unsigned int, int, char const*, ...)
        ???:0
0x8cf9c2 poplevel(int, int, int)
        ???:0
0xaa3603 do_poplevel(tree_node*)
        ???:0
0xaa84f9 finish_compound_stmt(tree_node*)
        ???:0
0xa45f47 instantiate_decl(tree_node*, bool, bool)
        ???:0
0x1501d13 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
        ???:0
0x150275c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
        ???:0
0x1505ef5 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*, false,
default_hash_traits<tree_node*> >*))
        ???:0
0xb20690 store_init_value(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int)
        ???:0
0x8d3fa9 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
        ???:0
0xa0c105 c_parse_file()
        ???:0
0xb93132 c_common_parse_file()
        ???:0
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.
Compiler returned: 1
// end error output

             reply	other threads:[~2021-10-28 12:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 12:49 peeceseven at gmail dot com [this message]
2021-10-28 12:50 ` [Bug c++/102987] [9,10,11,trunk] " peeceseven at gmail dot com
2021-10-28 12:52 ` peeceseven at gmail dot com
2021-10-29  6:38 ` [Bug c++/102987] [9/10/11/12 Regression] " rguenth at gcc dot gnu.org
2022-04-14 21:39 ` jason at gcc dot gnu.org
2022-04-15  1:00 ` cvs-commit at gcc dot gnu.org
2022-04-29 13:21 ` [Bug c++/102987] [9/10/11 " cvs-commit at gcc dot gnu.org
2022-05-27  9:46 ` [Bug c++/102987] [10/11 " rguenth at gcc dot gnu.org
2022-06-28 10:46 ` jakub at gcc dot gnu.org
2023-07-07 10:41 ` [Bug c++/102987] [11 " rguenth at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-102987-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).