public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1 Date: Mon, 29 Jun 2020 20:46:04 +0000 [thread overview] Message-ID: <bug-95984-4-uCyalAfHEw@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-95984-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95984 Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2020-06-29 CC| |jason at gcc dot gnu.org, | |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> --- If I'm reading the dump right the front end constructs a lambda object and calls its member operator() with a null this pointer: ;; Function static decltype (((const callback<main()::<lambda(int)> >::<lambda(auto:1 ...)>*)0)->operator()<auto:1 ...>(static_cast<auto:1&&>(callback::._anon_2::_FUN::<unnamed>) ...)) callback<main()::<lambda(int)> >::<lambda(auto:1 ...)>::_FUN(auto:1 ...) [with auto:1 = {int}; decltype (((const callback<main()::<lambda(int)> >::<lambda(auto:1 ...)>*)0)->operator()<auto:1 ...>(static_cast<auto:1&&>(callback::._anon_2::_FUN::<unnamed>) ...)) = void] (null) ;; enabled by -tree-original <<cleanup_point <<< Unknown tree: expr_stmt callback<main()::<lambda(int)> >::<lambda(auto:1 ...)>::operator()<int> (0B, D.2439) >>>>>; return; So it seems like the warning code is doing what it's supposed to. The ICE is triggered by the C++ front end printing the instantiation context (print_instantiation_full_context), the pretty printer formatting the template specialization, calling into the C++ front end to perform type substitution, and the FE ending up calling check_nonnull_arg() on the call, which ends up triggering the warning and re-entering the diagnostic machinery. There is nothing out of the ordinary the warning does to do this so it must be a latent problem in the C++ front end that the warning exposed. I expect Jason or Marek have seen and deal with something like this before.
next prev parent reply other threads:[~2020-06-29 20:46 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-29 18:36 [Bug tree-optimization/95984] New: " marxin at gcc dot gnu.org 2020-06-29 20:46 ` msebor at gcc dot gnu.org [this message] 2020-06-30 17:56 ` [Bug c++/95984] " dje at gcc dot gnu.org 2020-06-30 17:57 ` msebor at gcc dot gnu.org 2020-07-01 16:37 ` msebor at gcc dot gnu.org 2020-07-06 21:24 ` cvs-commit at gcc dot gnu.org 2020-07-06 21:25 ` msebor at gcc dot gnu.org 2020-07-08 7:55 ` slyfox at inbox dot ru
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-95984-4-uCyalAfHEw@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: linkBe 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).